August 2022 - Devel - libvirt List Archives

[libvirt PATCH 0/2] ci: Switch from macOS 11 to macOS 12
by Andrea Bolognani 24 Aug '22

24 Aug '22

Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/620665364 Now that the test suite issues that were blocking the switch have been addressed, we can finally jump on the current macOS release. Andrea Bolognani (2): ci: Refresh generated files ci: Switch from macOS 11 to macOS 12 ci/cirrus/{macos-11.vars => macos-12.vars} | 0 ci/containers/centos-stream-9.Dockerfile | 5 +++++ ci/containers/opensuse-leap-153.Dockerfile | 2 +- ci/containers/ubuntu-2004.Dockerfile | 2 +- ci/gitlab/builds.yml | 6 +++--- ci/manifest.yml | 2 +- 6 files changed, 11 insertions(+), 6 deletions(-) rename ci/cirrus/{macos-11.vars => macos-12.vars} (100%) -- 2.37.2

2 3

[libvirt PATCH] docs: fix syntax errors in IPv6 NAT example XML
by Daniel P. Berrangé 24 Aug '22

24 Aug '22

Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatnetwork.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst index 044c239985..b5dc29db07 100644 --- a/docs/formatnetwork.rst +++ b/docs/formatnetwork.rst @@ -930,13 +930,13 @@ routing. <nat ipv6='yes'> <port start='1024' end='65535'/> </nat> - + </forward> <ip address="192.168.122.1" netmask="255.255.255.0"> <dhcp> <range start="192.168.122.2" end="192.168.122.254"/> </dhcp> </ip> - <ip family="ipv6" address="fdXX:XXXX:XXXX:NNNN:: prefix="64"/> + <ip family="ipv6" address="fdXX:XXXX:XXXX:NNNN::" prefix="64"/> </network> IPv6 NAT addressing has some caveats over the more straight forward IPv4 case. -- 2.37.2

2 1

[PATCH] virhostcpu: Fix build with clang and newest kernel headers
by Peter Krempa 23 Aug '22

23 Aug '22

The most recent environment e.g. present in our Fedora Rawhide builds fail to build the tree with clang with the following error: ../src/util/virhostcpu.c:1291:25: error: field 'header' with variable sized type 'struct kvm_msrs' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end] struct kvm_msrs header; ^ The problem seems to be that clang doesn't like the new way the 'entries' field in struct kvm_msrs is declared. To work around the issue we can simply allocate the variable dynamically and use the 'entries' member as it was intended to to access the members. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virhostcpu.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 54d0166b85..c1e8dc8078 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1287,25 +1287,22 @@ virHostCPUGetMSRFromKVM(unsigned long index, uint64_t *result) { VIR_AUTOCLOSE fd = -1; - struct { - struct kvm_msrs header; - struct kvm_msr_entry entry; - } msr = { - .header = { .nmsrs = 1 }, - .entry = { .index = index }, - }; + g_autofree struct kvm_msrs *msr = g_malloc0(sizeof(struct kvm_msrs) + + sizeof(struct kvm_msr_entry)); + msr->nmsrs = 1; + msr->entries[0].index = index; if ((fd = open(KVM_DEVICE, O_RDONLY)) < 0) { virReportSystemError(errno, _("Unable to open %s"), KVM_DEVICE); return -1; } - if (ioctl(fd, KVM_GET_MSRS, &msr) < 0) { + if (ioctl(fd, KVM_GET_MSRS, msr) < 0) { VIR_DEBUG("Cannot get MSR 0x%lx from KVM", index); return 1; } - *result = msr.entry.data; + *result = msr->entries[0].data; return 0; } -- 2.37.1

4 5

[PATCH 0/7] qemu: tpm: Add support for migration across shared storage
by Stefan Berger 23 Aug '22

23 Aug '22

This series of patches adds support for migrating vTPMs across hosts whose storage has been set up to share the directory structure holding the state of the TPM (swtpm). The domain XML is extended with a shared_storage attribute that must be set to 'yes' when shared storage is used. It influences the management of the directory structure holding the TPM state, which for example is only to be removed when a domain is undefined (virsh undefine) and not when a VM is removed on the migration source host. Further, when shared storage is used security labeling on the destination side is skipped assuming that the labeling was already done on the source side. I have tested this with an NFS setup where I had to turn SELinux off on the hosts since the SELinux MLS range labeling is not supported. Share storage migration requires the upcoming swtpm v0.8 with the PR for shared storage merged: https://github.com/stefanberger/swtpm/pull/732 Stefan Stefan Berger (7): qemu: tpm: Pass parameter indicating reason for domain removal util: Add parsing support for swtpm's cmdarg-migration capability qemu: tpm: Conditionally create storage on incoming migration qemu: tpm: Pass --migration option to swtpm when using shared storage qemu: tpm: Avoid security labels on incoming migration with shared storage qemu: tpm: Remove TPM state files and directory only when undefining a VM qemu: config: Extend TPM domain XML with shared storage support docs/formatdomain.rst | 16 ++++++++ src/conf/domain_conf.c | 13 +++++++ src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 5 +++ src/qemu/qemu_domain.c | 12 +++--- src/qemu/qemu_domain.h | 8 +++- src/qemu/qemu_driver.c | 20 +++++----- src/qemu/qemu_extdevice.c | 5 ++- src/qemu/qemu_extdevice.h | 3 +- src/qemu/qemu_migration.c | 13 ++++--- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_snapshot.c | 4 +- src/qemu/qemu_tpm.c | 61 ++++++++++++++++++++++++++----- src/qemu/qemu_tpm.h | 3 +- src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + 16 files changed, 131 insertions(+), 39 deletions(-) -- 2.37.1

2 16

[PATCH 0/4] docs: Fix generation of hyperlinks and improve backup/checkpoint docs
by Peter Krempa 23 Aug '22

23 Aug '22

Peter Krempa (4): docs: newapi: Consider also 'https://' links in the API generator XSL virDomainCheckpointCreateXML: Don't use HTML in function docs and fix link virDomainCheckpointCreateXML: Add disclaimer about creating checkpoints virDomainBackupGetXMLDesc: Fix and use full link to XML documentation docs/newapi.xsl | 5 +++++ src/libvirt-domain-checkpoint.c | 12 +++++++++++- src/libvirt-domain.c | 2 +- 3 files changed, 17 insertions(+), 2 deletions(-) -- 2.37.1

2 6

[PATCH] lib: Don't check for retval for virCommandNew*()
by Michal Privoznik 23 Aug '22

23 Aug '22

The virCommand module is specifically designed so that no caller has to check for retval of individual virCommand*() APIs except for virCommandRun() where the actual error is reported. Moreover, virCommandNew*() use g_new0() to allocate memory and thus it's not really possible for those APIs to return NULL. Which is why they are even marked as ATTRIBUTE_NONNULL. But there are few places where we do check the retval which is a dead code effectively. Drop those checks. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_slirp.c | 3 +-- src/qemu/qemu_tpm.c | 10 ---------- src/qemu/qemu_vhost_user_gpu.c | 2 -- src/qemu/qemu_virtiofs.c | 3 +-- src/util/virtpm.c | 3 +-- tests/virshtest.c | 3 +-- 6 files changed, 4 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_slirp.c b/src/qemu/qemu_slirp.c index c802ef7fa8..3f83db03bf 100644 --- a/src/qemu/qemu_slirp.c +++ b/src/qemu/qemu_slirp.c @@ -268,8 +268,7 @@ qemuSlirpStart(virDomainObj *vm, if (!(pidfile = qemuSlirpCreatePidFilename(cfg, vm->def, net->info.alias))) return -1; - if (!(cmd = virCommandNew(cfg->slirpHelperName))) - return -1; + cmd = virCommandNew(cfg->slirpHelperName); virCommandClearCaps(cmd); virCommandSetPidFile(cmd, pidfile); diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index 584c787b70..d0aed7fa2e 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -279,8 +279,6 @@ qemuTPMCreateConfigFiles(const char *swtpm_setup) return 0; cmd = virCommandNew(swtpm_setup); - if (!cmd) - return -1; virCommandAddArgList(cmd, "--create-config-files", "skip-if-exist", NULL); virCommandClearCaps(cmd); @@ -388,8 +386,6 @@ qemuTPMEmulatorRunSetup(const char *storagepath, return -1; cmd = virCommandNew(swtpm_setup); - if (!cmd) - return -1; virUUIDFormat(vmuuid, uuid); vmid = g_strdup_printf("%s:%s", vmname, uuid); @@ -500,8 +496,6 @@ qemuTPMEmulatorReconfigure(const char *storagepath, return 0; cmd = virCommandNew(swtpm_setup); - if (!cmd) - return -1; virCommandSetUID(cmd, swtpm_user); virCommandSetGID(cmd, swtpm_group); @@ -592,8 +586,6 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm, unlink(tpm->data.emulator.source->data.nix.path); cmd = virCommandNew(swtpm); - if (!cmd) - goto error; virCommandClearCaps(cmd); @@ -806,8 +798,6 @@ qemuTPMEmulatorStop(const char *swtpmStateDir, return; cmd = virCommandNew(swtpm_ioctl); - if (!cmd) - return; virCommandAddArgList(cmd, "--unix", pathname, "-s", NULL); diff --git a/src/qemu/qemu_vhost_user_gpu.c b/src/qemu/qemu_vhost_user_gpu.c index 7c5be4098e..bc5a1dc3ec 100644 --- a/src/qemu/qemu_vhost_user_gpu.c +++ b/src/qemu/qemu_vhost_user_gpu.c @@ -133,8 +133,6 @@ int qemuExtVhostUserGPUStart(virQEMUDriver *driver, goto error; cmd = virCommandNew(video->driver->vhost_user_binary); - if (!cmd) - goto error; virCommandClearCaps(cmd); virCommandSetPidFile(cmd, pidfile); diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c index ce55286ab5..a04aa08e39 100644 --- a/src/qemu/qemu_virtiofs.c +++ b/src/qemu/qemu_virtiofs.c @@ -132,8 +132,7 @@ qemuVirtioFSBuildCommandLine(virQEMUDriverConfig *cfg, g_autoptr(virCommand) cmd = NULL; g_auto(virBuffer) opts = VIR_BUFFER_INITIALIZER; - if (!(cmd = virCommandNew(fs->binary))) - return NULL; + cmd = virCommandNew(fs->binary); virCommandAddArgFormat(cmd, "--fd=%d", *fd); virCommandPassFD(cmd, *fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT); diff --git a/src/util/virtpm.c b/src/util/virtpm.c index 2f2b061fee..91db0f31eb 100644 --- a/src/util/virtpm.c +++ b/src/util/virtpm.c @@ -252,8 +252,7 @@ virTPMGetCaps(virTPMBinaryCapsParse capsParse, { g_autoptr(virCommand) cmd = NULL; - if (!(cmd = virCommandNew(exec))) - return NULL; + cmd = virCommandNew(exec); if (param1) virCommandAddArg(cmd, param1); diff --git a/tests/virshtest.c b/tests/virshtest.c index a53a6273b9..3d297a1db2 100644 --- a/tests/virshtest.c +++ b/tests/virshtest.c @@ -116,8 +116,7 @@ testCompareOutputLit(const char *expectData, g_autoptr(virCommand) cmd = NULL; g_autofree char *errbuf = NULL; - if (!(cmd = virCommandNewArgs(argv))) - return -1; + cmd = virCommandNewArgs(argv); virCommandAddEnvString(cmd, "LANG=C"); virCommandSetInputBuffer(cmd, empty); -- 2.35.1

2 1

[PATCH v14 00/15] Support query and use SGX
by Michal Privoznik 23 Aug '22

23 Aug '22

As agreed here, I've taken posted patches, did some changes and fixes and posted them: https://listman.redhat.com/archives/libvir-list/2022-July/233164.html The v13 version can be found here: https://listman.redhat.com/archives/libvir-list/2022-July/232679.html diff to v13: - I've worked my comments in (couple of memleaks, naming issues, ...) - Fixed problem with CGroups and namespaces - Fixed a problem with <memoryBacking> <source type='memfd'/>, which prevented domain from starting. Simply because wrong memory-backend was picked for SGX (-memfd was picked instead of -sgx). - Some cleanups, formatted before original patches (more tests, validation, code separation, ...) You can find these patches on my gitlab (among with green pipeline): https://gitlab.com/MichalPrivoznik/libvirt/-/commits/sgx_rework Haibin Huang (4): domain_capabilities: Define SGX capabilities structs qemu: Get SGX capabilities form QMP Convert QMP capabilities to domain capabilities conf: expose SGX feature in domain capabilities Lin Yang (2): conf: Introduce SGX EPC element into device memory xml qemu: Add command-line to generate SGX EPC memory backend Michal Prívozník (9): qemuxml2argvtest: Switch memory-hotplug-dimm-addr to latest caps qemuxml2xmltest: Test memory-hotplug-dimm-addr conf: Validate virDomainMemoryDef::targetNode qemu_command: Separate domain features building into a helper qemu_command: Separate domain memory building into a helper qemu_cgroup: Don't ignore ENOENT in qemuCgroupAllowDevicesPaths() qemu_cgroup: Allow SGX in devices controller qemu_namespace: Create SGX related nodes in domain's namespace security_dac: Set DAC label on SGX /dev nodes docs/formatdomain.rst | 25 +- docs/formatdomaincaps.rst | 40 +++ src/conf/domain_capabilities.c | 46 +++ src/conf/domain_capabilities.h | 22 ++ src/conf/domain_conf.c | 30 ++ src/conf/domain_conf.h | 1 + src/conf/domain_postparse.c | 1 + src/conf/domain_validate.c | 22 ++ src/conf/schemas/domaincaps.rng | 40 +++ src/conf/schemas/domaincommon.rng | 1 + src/libvirt_private.syms | 1 + src/qemu/qemu_alias.c | 6 +- src/qemu/qemu_capabilities.c | 222 +++++++++++++ src/qemu/qemu_capabilities.h | 6 + src/qemu/qemu_cgroup.c | 82 ++++- src/qemu/qemu_command.c | 293 +++++++++++------- src/qemu/qemu_domain.c | 48 ++- src/qemu/qemu_domain.h | 2 + src/qemu/qemu_domain_address.c | 6 + src/qemu/qemu_driver.c | 1 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 148 ++++++++- src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 20 +- src/qemu/qemu_process.c | 2 + src/qemu/qemu_validate.c | 8 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 44 ++- src/security/security_selinux.c | 2 + tests/domaincapsdata/bhyve_basic.x86_64.xml | 1 + tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 1 + tests/domaincapsdata/bhyve_uefi.x86_64.xml | 1 + tests/domaincapsdata/empty.xml | 1 + tests/domaincapsdata/libxl-xenfv.xml | 1 + tests/domaincapsdata/libxl-xenpv.xml | 1 + .../domaincapsdata/qemu_3.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_3.1.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_3.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 1 + .../qemu_4.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_4.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_4.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 + .../qemu_4.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 1 + .../qemu_5.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_5.1.0.sparc.xml | 1 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 1 + .../qemu_5.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_5.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 1 + .../qemu_6.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 6 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 6 + .../qemu_6.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 6 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 10 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 10 + .../qemu_7.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 10 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 10 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 10 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 10 + .../caps_6.2.0.x86_64.replies | 24 +- .../caps_6.2.0.x86_64.xml | 7 + .../caps_7.0.0.x86_64.replies | 34 +- .../caps_7.0.0.x86_64.xml | 11 + .../caps_7.1.0.x86_64.replies | 34 +- .../caps_7.1.0.x86_64.xml | 11 + .../aarch64-aavmf-virtio-mmio.args | 2 +- .../aarch64-cpu-passthrough.args | 2 +- ...fault-cpu-kvm-virt-4.2.aarch64-latest.args | 2 +- ...fault-cpu-tcg-virt-4.2.aarch64-latest.args | 2 +- .../aarch64-features-sve.aarch64-latest.args | 2 +- tests/qemuxml2argvdata/aarch64-gic-host.args | 2 +- .../aarch64-gic-none-tcg.args | 2 +- tests/qemuxml2argvdata/aarch64-gic-v2.args | 2 +- tests/qemuxml2argvdata/aarch64-gic-v3.args | 2 +- .../qemuxml2argvdata/aarch64-pci-serial.args | 2 +- .../aarch64-tpm.aarch64-latest.args | 2 +- .../aarch64-traditional-pci.args | 2 +- .../aarch64-usb-controller-nec-xhci.args | 2 +- .../aarch64-usb-controller-qemu-xhci.args | 2 +- .../aarch64-video-default.args | 2 +- .../aarch64-video-virtio-gpu-pci.args | 2 +- .../aarch64-virt-2.6-virtio-pci-default.args | 2 +- .../aarch64-virt-default-nic.args | 2 +- .../aarch64-virt-graphics.aarch64-latest.args | 2 +- .../aarch64-virt-headless.aarch64-latest.args | 2 +- .../qemuxml2argvdata/aarch64-virt-virtio.args | 2 +- .../aarch64-virtio-pci-default.args | 2 +- .../aarch64-virtio-pci-manual-addresses.args | 2 +- .../balloon-mmio-deflate.args | 2 +- .../clock-timer-armvtimer.aarch64-latest.args | 2 +- ...ult-video-type-aarch64.aarch64-latest.args | 2 +- ...mware-auto-efi-aarch64.aarch64-latest.args | 2 +- ...-auto-efi-enrolled-keys.x86_64-latest.args | 2 +- ...-auto-efi-loader-secure.x86_64-latest.args | 2 +- ...to-efi-no-enrolled-keys.x86_64-latest.args | 2 +- ...are-auto-efi-no-secboot.x86_64-latest.args | 2 +- ...firmware-auto-efi-nvram.x86_64-latest.args | 2 +- ...rmware-auto-efi-secboot.x86_64-latest.args | 2 +- ...ware-auto-efi-stateless.x86_64-latest.args | 2 +- .../firmware-auto-efi.x86_64-latest.args | 2 +- ...manual-bios-rw-implicit.x86_64-latest.args | 2 +- ...firmware-manual-bios-rw.x86_64-latest.args | 2 +- .../firmware-manual-efi-acpi-aarch64.args | 2 +- .../firmware-manual-efi-noacpi-aarch64.args | 2 +- ...e-manual-efi-nvram-file.x86_64-latest.args | 2 +- ...efi-nvram-network-iscsi.x86_64-latest.args | 2 +- ...l-efi-nvram-network-nbd.x86_64-latest.args | 2 +- ...nual-efi-nvram-template.x86_64-latest.args | 2 +- ...re-manual-efi-stateless.x86_64-latest.args | 2 +- .../firmware-manual-noefi-noacpi-aarch64.args | 2 +- .../hvf-aarch64-virt-headless.args | 2 +- .../intel-iommu-aw-bits.x86_64-latest.args | 2 +- ...ntel-iommu-caching-mode.x86_64-latest.args | 2 +- ...ntel-iommu-device-iotlb.x86_64-latest.args | 2 +- .../intel-iommu-eim.x86_64-latest.args | 2 +- .../iommu-smmuv3.aarch64-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- ...nch-security-sev-direct.x86_64-latest.args | 2 +- ...ev-missing-platform-info.x86_64-6.0.0.args | 2 +- .../launch-security-sev.x86_64-6.0.0.args | 2 +- .../mach-virt-console-virtio.args | 2 +- .../mach-virt-serial-native.args | 2 +- .../mach-virt-serial-pci.args | 2 +- .../mach-virt-serial-usb.args | 2 +- .../machine-aeskeywrap-off-cap.args | 2 +- .../machine-aeskeywrap-off-caps.args | 2 +- .../machine-aeskeywrap-on-cap.args | 2 +- .../machine-aeskeywrap-on-caps.args | 2 +- .../machine-deakeywrap-off-cap.args | 2 +- .../machine-deakeywrap-off-caps.args | 2 +- .../machine-deakeywrap-on-cap.args | 2 +- .../machine-deakeywrap-on-caps.args | 2 +- ...emory-hotplug-dimm-addr.x86_64-latest.args | 42 +++ .../memory-hotplug-dimm-addr.xml | 2 +- .../memory-hotplug-invalid-targetnode.err | 1 + .../memory-hotplug-invalid-targetnode.xml | 42 +++ ...e-expander-bus-aarch64.aarch64-latest.args | 2 +- ...eries-cpu-compat-power10.ppc64-latest.args | 2 +- ...series-cpu-compat-power9.ppc64-latest.args | 2 +- tests/qemuxml2argvdata/pseries-features.args | 2 +- .../sgx-epc-numa.x86_64-latest.args | 40 +++ tests/qemuxml2argvdata/sgx-epc-numa.xml | 64 ++++ ...mm-addr.args => sgx-epc.x86_64-6.2.0.args} | 29 +- tests/qemuxml2argvdata/sgx-epc.xml | 52 ++++ .../virtio-iommu-aarch64.aarch64-latest.args | 2 +- tests/qemuxml2argvtest.c | 7 +- ...memory-hotplug-dimm-addr.x86_64-latest.xml | 63 ++++ .../sgx-epc-numa.x86_64-latest.xml | 1 + .../sgx-epc.x86_64-6.2.0.xml | 1 + tests/qemuxml2xmltest.c | 4 + 189 files changed, 1621 insertions(+), 266 deletions(-) create mode 100644 tests/qemuxml2argvdata/memory-hotplug-dimm-addr.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-invalid-targetnode.err create mode 100644 tests/qemuxml2argvdata/memory-hotplug-invalid-targetnode.xml create mode 100644 tests/qemuxml2argvdata/sgx-epc-numa.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/sgx-epc-numa.xml rename tests/qemuxml2argvdata/{memory-hotplug-dimm-addr.args => sgx-epc.x86_64-6.2.0.args} (39%) create mode 100644 tests/qemuxml2argvdata/sgx-epc.xml create mode 100644 tests/qemuxml2xmloutdata/memory-hotplug-dimm-addr.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/sgx-epc-numa.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/sgx-epc.x86_64-6.2.0.xml -- 2.35.1

6 41

Plans for the next release
by Jiri Denemark 23 Aug '22

23 Aug '22

We are getting close to the next release of libvirt. To aim for the release on Sep 01 I suggest entering the freeze on Friday Aug 26 and tagging RC2 on Tuesday Aug 30. I hope this works for everyone. Jirka

1 0

[libvirt PATCH] nwfilter: Fix timeout data type reported by coverity
by Erik Skultety 23 Aug '22

23 Aug '22

Coverity reports: virNWFilterSnoopIPLeaseUpdate(virNWFilterSnoopIPLease *ipl, time_t timeout) { if (timeout < ipl->timeout) return; /* no take-backs */ virNWFilterSnoopIPLeaseTimerDel(ipl); >>> CID 396747: High impact quality (Y2K38_SAFETY) >>> A "time_t" value is stored in an integer with too few bits to accommodate it. The expression "timeout" is cast to "unsigned int". ipl->timeout = timeout; virNWFilterSnoopIPLeaseTimerAdd(ipl); } This is a safe fix, since time_t is just long int and scales automatically with platform (more specifically it's 64bit on all platforms we care about). Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- src/nwfilter/nwfilter_dhcpsnoop.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/nwfilter/nwfilter_dhcpsnoop.c b/src/nwfilter/nwfilter_dhcpsnoop.c index a10a14cfc1..4133d4c672 100644 --- a/src/nwfilter/nwfilter_dhcpsnoop.c +++ b/src/nwfilter/nwfilter_dhcpsnoop.c @@ -146,7 +146,7 @@ struct _virNWFilterSnoopIPLease { virSocketAddr ipAddress; virSocketAddr ipServer; virNWFilterSnoopReq * snoopReq; - unsigned int timeout; + time_t timeout; /* timer list */ virNWFilterSnoopIPLease *prev; virNWFilterSnoopIPLease *next; @@ -1580,7 +1580,7 @@ virNWFilterSnoopLeaseFileWrite(int lfd, const char *ifkey, return -1; /* time intf ip dhcpserver */ - lbuf = g_strdup_printf("%u %s %s %s\n", ipl->timeout, ifkey, ipstr, dhcpstr); + lbuf = g_strdup_printf("%lu %s %s %s\n", ipl->timeout, ifkey, ipstr, dhcpstr); len = strlen(lbuf); if (safewrite(lfd, lbuf, len) != len) { @@ -1739,7 +1739,7 @@ virNWFilterSnoopLeaseFileLoad(void) } ln++; /* key len 54 = "VMUUID"+'-'+"MAC" */ - if (sscanf(line, "%u %54s %15s %15s", &ipl.timeout, + if (sscanf(line, "%lu %54s %15s %15s", &ipl.timeout, ifkey, ipstr, srvstr) < 4) { virReportError(VIR_ERR_INTERNAL_ERROR, _("virNWFilterSnoopLeaseFileLoad lease file " -- 2.37.2

3 2

[libvirt PATCH] qemu: adjust memlock for multiple vfio/vdpa devices
by Jonathon Jongsma 23 Aug '22

23 Aug '22

When multiple VFIO or VDPA devices are assigned to a guest, the guest can fail to start because the guest fails to map enough memory. For example, the case mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1994893 results in this failure: 2021-08-05T09:51:47.692578Z qemu-kvm: failed to write, fd=24, errno=14 (Bad address) 2021-08-05T09:51:47.692590Z qemu-kvm: vhost vdpa map fail! 2021-08-05T09:51:47.692594Z qemu-kvm: vhost-vdpa: DMA mapping failed, unable to continue The current memlock limit calculation does not work for scenarios where there are multiple such devices assigned to a guest. The root causes are a little bit different between VFIO and VDPA devices. For VFIO devices, the issue only occurs when a vIOMMU is present. In this scenario, each vfio device is assigned a separate AddressSpace fully mapping guest RAM. When there is no vIOMMU, the devices are all within the same AddressSpace so no additional memory limit is needed. For VDPA devices, each device requires the full memory to be mapped regardless of whether there is a vIOMMU or not. In order to enable these scenarios, we need to multiply memlock limit by the number of VDPA devices plus the number of VFIO devices for guests with a vIOMMU. This has the potential for pushing the memlock limit above the host physical memory and negating any protection that these locked memory limits are providing, but there is no other short-term solution. In the future, there should be have a revised userspace iommu interface (iommufd) that the VFIO and VDPA backends can make use of. This will be able to share locked memory limits between both vfio and vdpa use cases and address spaces and then we can disable these short term hacks. But this is still in development upstream. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/qemu/qemu_domain.c | 56 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 54 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 45f00e162d..a1e91ef48f 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9233,6 +9233,40 @@ getPPC64MemLockLimitBytes(virDomainDef *def, } +static int +qemuDomainGetNumVFIODevices(const virDomainDef *def) +{ + int i; + int n = 0; + + for (i = 0; i < def->nhostdevs; i++) { + if (virHostdevIsVFIODevice(def->hostdevs[i]) || + virHostdevIsMdevDevice(def->hostdevs[i])) + n++; + } + for (i = 0; i < def->ndisks; i++) { + if (virStorageSourceChainHasNVMe(def->disks[i]->src)) + n++; + } + return n; +} + + +static int +qemuDomainGetNumVDPANetDevices(const virDomainDef *def) +{ + int i; + int n = 0; + + for (i = 0; i < def->nnets; i++) { + if (virDomainNetGetActualType(def->nets[i]) == VIR_DOMAIN_NET_TYPE_VDPA) + n++; + } + + return n; +} + + /** * qemuDomainGetMemLockLimitBytes: * @def: domain definition @@ -9252,6 +9286,8 @@ qemuDomainGetMemLockLimitBytes(virDomainDef *def, bool forceVFIO) { unsigned long long memKB = 0; + int nvfio; + int nvdpa; /* prefer the hard limit */ if (virMemoryLimitIsSet(def->mem.hard_limit)) { @@ -9270,6 +9306,8 @@ qemuDomainGetMemLockLimitBytes(virDomainDef *def, if (ARCH_IS_PPC64(def->os.arch) && def->virtType == VIR_DOMAIN_VIRT_KVM) return getPPC64MemLockLimitBytes(def, forceVFIO); + nvfio = qemuDomainGetNumVFIODevices(def); + nvdpa = qemuDomainGetNumVDPANetDevices(def); /* For device passthrough using VFIO the guest memory and MMIO memory * regions need to be locked persistent in order to allow DMA. * @@ -9288,8 +9326,22 @@ qemuDomainGetMemLockLimitBytes(virDomainDef *def, * * Note that this may not be valid for all platforms. */ - if (forceVFIO || qemuDomainNeedsVFIO(def) || virDomainDefHasVDPANet(def)) - memKB = virDomainDefGetMemoryTotal(def) + 1024 * 1024; + if (forceVFIO || nvfio || nvdpa) { + /* At present, the full memory needs to be locked for each VFIO / VDPA + * device. For VFIO devices, this only applies when there is a vIOMMU + * present. Yes, this may result in a memory limit that is greater than + * the host physical memory, which is not ideal. The long-term solution + * is a new userspace iommu interface (iommufd) which should eliminate + * this duplicate memory accounting. But for now this is the only way + * to enable configurations with e.g. multiple vdpa devices. + */ + int factor = nvdpa; + + if (def->iommu) + factor += nvfio; + + memKB = MAX(factor, 1) * virDomainDefGetMemoryTotal(def) + 1024 * 1024; + } return memKB << 10; } -- 2.37.1

2 1

[libvirt PATCH] libxl: Fix build with recent Xen that introduces new disk backend type
by Oleksandr Tyshchenko 22 Aug '22

22 Aug '22

From: Oleksandr Tyshchenko <oleksandr_tyshchenko(a)epam.com> Xen toolstack has gained basic Virtio support recently which becides adding various virtio related stuff introduces new disk backend type LIBXL_DISK_BACKEND_STANDALONE [1]. Unfortunately, this caused a regression in libvirt build with Xen support enabled, reported by the osstest today [2]: CC libxl/libvirt_driver_libxl_impl_la-xen_xl.lo ../../src/libxl/xen_xl.c: In function 'xenParseXLDisk': ../../src/libxl/xen_xl.c:779:17: error: enumeration value 'LIBXL_DISK_BACKEND_STANDALONE' not handled in switch [-Werror=switch-enum] switch (libxldisk->backend) { ^~~~~~ cc1: all warnings being treated as errors The interesting fact is that switch already has a default branch (which ought to cover such new addition), but the error is triggered as -Wswitch-enum gives a warning about an omitted enumeration code even if there is a default label. Also there is a similar issue in libxlUpdateDiskDef() which I have reproduced after fixing the first one, but it that case the corresponding switch doesn't have a default branch. Fix both issues by inserting required enumeration item to make the compiler happy and adding ifdef guard to be able to build against old Xen libraries as well (without LIBXL_HAVE_DEVICE_DISK_SPECIFICATION). Also add a default branch to switch in libxlUpdateDiskDef(). Please note, that current patch doesn't implement the proper handling of LIBXL_DISK_BACKEND_STANDALONE and friends, it is just intended to fix the regression immediately to unblock the osstest. Also it worth mentioning that current patch won't solve the possible additions in the future. [1] https://lore.kernel.org/xen-devel/20220716163745.28712-1-olekstysh@gmail.co… [2] https://lore.kernel.org/xen-devel/E1oHEQO-0008GA-Uo@osstest.test-lab.xenpro… Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko(a)epam.com> --- Cc: Julien Grall <julien(a)xen.org> Cc: Anthony PERARD <anthony.perard(a)citrix.com> Cc: Michal Privoznik <mprivozn(a)redhat.com> Please note, the patch is tested on: https://xenbits.xen.org/gitweb/?p=libvirt.git;a=shortlog;h=refs/heads/xen-t… but should work on the master as well (as the same code is present here). --- src/libxl/libxl_conf.c | 4 ++++ src/libxl/xen_xl.c | 3 +++ 2 files changed, 7 insertions(+) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index aa3d7925ec..526f0b2b08 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -1240,6 +1240,10 @@ libxlUpdateDiskDef(virDomainDiskDef *l_disk, libxl_device_disk *x_disk) driver = "phy"; break; case LIBXL_DISK_BACKEND_UNKNOWN: +#ifdef LIBXL_HAVE_DEVICE_DISK_SPECIFICATION + case LIBXL_DISK_BACKEND_STANDALONE: +#endif + default: break; } if (driver) diff --git a/src/libxl/xen_xl.c b/src/libxl/xen_xl.c index 4de4e3140f..6919325623 100644 --- a/src/libxl/xen_xl.c +++ b/src/libxl/xen_xl.c @@ -715,6 +715,9 @@ xenParseXLDisk(virConf *conf, virDomainDef *def) virDomainDiskSetDriver(disk, "phy"); virDomainDiskSetType(disk, VIR_STORAGE_TYPE_BLOCK); break; +#ifdef LIBXL_HAVE_DEVICE_DISK_SPECIFICATION + case LIBXL_DISK_BACKEND_STANDALONE: +#endif default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("disk backend not supported: %s"), -- 2.25.1

7 12

[libvirt PATCH 00/16] various network driver cleanups
by Laine Stump 22 Aug '22

22 Aug '22

These all bubbled to the top of a series that adds support for an nftables backend to the network driver, but are valid patches by themselves, so I'm sending them separately to make the other series look shorter. Laine Stump (16): conf: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) esx: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) network: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) qemu: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) test driver: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) vbox: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) tests: replace explicit virNetworkDefFree() with g_autoptr(virNetworkDef) conf: remove superfluous cleanup: labels and ret return variables qemu: remove superfluous cleanup: labels and ret return variables tests: remove superfluous cleanup: labels and ret return variables network: move driver state struct into bridge_driver_conf.h network: create separate config object for virNetworkDriverState util: replace g_snprintf with g_autofreed g_strdup_printf in viriptables.c util: remove unused function virFirewallApplyRuleFirewallD() util: make virFirewallRuleToString() global util: don't use virFirewallRuleToString() to log the rule being applied po/POTFILES | 1 + src/conf/domain_conf.c | 26 +-- src/conf/virnetworkobj.c | 72 ++++----- src/esx/esx_network_driver.c | 6 +- src/libvirt_private.syms | 1 + src/network/bridge_driver.c | 233 ++++++++++++--------------- src/network/bridge_driver_conf.c | 165 +++++++++++++++++++ src/network/bridge_driver_conf.h | 82 ++++++++++ src/network/bridge_driver_platform.h | 43 +---- src/network/meson.build | 1 + src/qemu/qemu_process.c | 24 ++- src/test/test_driver.c | 6 +- src/util/virfirewall.c | 28 ++-- src/util/virfirewall.h | 3 + src/util/viriptables.c | 15 +- src/vbox/vbox_network.c | 6 +- tests/networkxml2firewalltest.c | 15 +- tests/networkxml2xmltest.c | 3 +- tests/networkxml2xmlupdatetest.c | 8 +- 19 files changed, 443 insertions(+), 295 deletions(-) create mode 100644 src/network/bridge_driver_conf.c create mode 100644 src/network/bridge_driver_conf.h -- 2.37.1

2 17

[libvirt PATCH 0/6] qemu: retire three more capabilities
by Ján Tomko 22 Aug '22

22 Aug '22

Ján Tomko (6): qemu: always assume QEMU_CAPS_DUMP_GUEST_MEMORY qemu: retire QEMU_CAPS_DUMP_GUEST_MEMORY qemu: always assume QEMU_CAPS_*_HOLE64_SIZE qemu: Retire QEMU_CAPS_I440FX_PCI_HOLE64_SIZE qemu: retire QEMU_CAPS_Q35_PCI_HOLE64_SIZE qemu: do not probe for -pcihost properties src/qemu/qemu_capabilities.c | 21 +- src/qemu/qemu_capabilities.h | 6 +- src/qemu/qemu_driver.c | 6 - src/qemu/qemu_validate.c | 14 - .../caps_4.2.0.aarch64.replies | 140 ++++---- .../caps_4.2.0.aarch64.xml | 1 - .../caps_4.2.0.ppc64.replies | 128 +++----- .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - .../caps_4.2.0.s390x.replies | 114 +++---- .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - .../caps_4.2.0.x86_64.replies | 264 ++++----------- .../caps_4.2.0.x86_64.xml | 3 - .../caps_5.0.0.aarch64.replies | 144 ++++----- .../caps_5.0.0.aarch64.xml | 1 - .../caps_5.0.0.ppc64.replies | 140 ++++---- .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - .../caps_5.0.0.riscv64.replies | 128 +++----- .../caps_5.0.0.riscv64.xml | 1 - .../caps_5.0.0.x86_64.replies | 277 ++++------------ .../caps_5.0.0.x86_64.xml | 3 - .../caps_5.1.0.sparc.replies | 86 ++--- .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - .../caps_5.1.0.x86_64.replies | 291 ++++------------- .../caps_5.1.0.x86_64.xml | 3 - .../caps_5.2.0.aarch64.replies | 148 ++++----- .../caps_5.2.0.aarch64.xml | 1 - .../caps_5.2.0.ppc64.replies | 140 ++++---- .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - .../caps_5.2.0.riscv64.replies | 128 +++----- .../caps_5.2.0.riscv64.xml | 1 - .../caps_5.2.0.s390x.replies | 118 +++---- .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - .../caps_5.2.0.x86_64.replies | 291 ++++------------- .../caps_5.2.0.x86_64.xml | 3 - .../caps_6.0.0.aarch64.replies | 148 ++++----- .../caps_6.0.0.aarch64.xml | 1 - .../caps_6.0.0.s390x.replies | 118 +++---- .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - .../caps_6.0.0.x86_64.replies | 291 ++++------------- .../caps_6.0.0.x86_64.xml | 3 - .../caps_6.1.0.x86_64.replies | 301 ++++-------------- .../caps_6.1.0.x86_64.xml | 3 - .../caps_6.2.0.aarch64.replies | 148 ++++----- .../caps_6.2.0.aarch64.xml | 1 - .../caps_6.2.0.ppc64.replies | 140 ++++---- .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 - .../caps_6.2.0.x86_64.replies | 301 ++++-------------- .../caps_6.2.0.x86_64.xml | 3 - .../caps_7.0.0.aarch64.replies | 152 ++++----- .../caps_7.0.0.aarch64.xml | 1 - .../caps_7.0.0.ppc64.replies | 140 ++++---- .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 - .../caps_7.0.0.x86_64.replies | 301 ++++-------------- .../caps_7.0.0.x86_64.xml | 3 - .../caps_7.1.0.x86_64.replies | 301 ++++-------------- .../caps_7.1.0.x86_64.xml | 3 - tests/qemuxml2argvdata/pcihole64-none.err | 1 - tests/qemuxml2argvdata/pcihole64-none.xml | 25 -- tests/qemuxml2argvtest.c | 6 +- tests/qemuxml2xmloutdata/pcihole64-none.xml | 30 -- tests/qemuxml2xmltest.c | 8 +- 61 files changed, 1457 insertions(+), 3582 deletions(-) delete mode 100644 tests/qemuxml2argvdata/pcihole64-none.err delete mode 100644 tests/qemuxml2argvdata/pcihole64-none.xml delete mode 100644 tests/qemuxml2xmloutdata/pcihole64-none.xml -- 2.37.1

2 8

[libvirt PATCH v4 0/6] Add support for 'blob' to virtio video device
by Jonathon Jongsma 19 Aug '22

19 Aug '22

Add support to libvirt for the 'blob' option for virtio video devices in qemu. Also do a little preparatory refactoring of the video device xml parsing code. I sent this series out a couple times but didn't get much review. Sending out again after fixing a few minor test- and doc-related things discussed in the last version and rebasing to current master branch. changes in v4: - rebased to latest master - updated tests changes in v3: - rebased to latest master Changes in v2: - Added some basic documentation - add a qemu capability - Make sure that the /dev/udmabuf device is accessible to qemu (cgroups, etc) Jonathon Jongsma (6): conf: Refactor video model parsing conf: switch to virXMLProp* functions conf: use enum variable for video type conf: add support for 'blob' in virtio video device qemu: Add capability for virtio-gpu.blob qemu: Implement 'blob' support for virtio gpu docs/formatdomain.rst | 7 + src/conf/domain_conf.c | 133 +++++++++--------- src/conf/domain_conf.h | 3 +- src/conf/domain_validate.c | 13 +- src/conf/schemas/domaincommon.rng | 5 + src/libxl/libxl_conf.c | 10 ++ src/libxl/libxl_domain.c | 11 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 22 ++- src/qemu/qemu_command.c | 3 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_monitor_json.c | 16 ++- src/qemu/qemu_namespace.c | 22 +++ src/qemu/qemu_process.c | 7 + src/qemu/qemu_validate.c | 9 ++ .../caps_6.1.0.x86_64.xml | 1 + .../caps_6.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 + .../caps_6.2.0.x86_64.xml | 1 + .../caps_7.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 + .../caps_7.0.0.x86_64.xml | 1 + .../caps_7.1.0.x86_64.xml | 1 + ...ideo-virtio-blob-absent.x86_64-latest.args | 39 +++++ .../video-virtio-blob-absent.xml | 36 +++++ .../video-virtio-blob-off.x86_64-latest.args | 39 +++++ .../video-virtio-blob-off.xml | 36 +++++ .../video-virtio-blob-on.x86_64-latest.args | 39 +++++ .../qemuxml2argvdata/video-virtio-blob-on.xml | 36 +++++ tests/qemuxml2argvtest.c | 3 + ...video-virtio-blob-absent.x86_64-latest.xml | 48 +++++++ .../video-virtio-blob-off.x86_64-latest.xml | 48 +++++++ .../video-virtio-blob-on.x86_64-latest.xml | 48 +++++++ tests/qemuxml2xmltest.c | 3 + 35 files changed, 567 insertions(+), 81 deletions(-) create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-absent.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-off.xml create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/video-virtio-blob-on.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-absent.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-off.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/video-virtio-blob-on.x86_64-latest.xml -- 2.37.1

1 6

[libvirt PATCH] tests: Drop irrelevant CPU config from graphics-spice-timeout
by Jiri Denemark 18 Aug '22

18 Aug '22

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/243 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- .../graphics-spice-timeout.x86_64-latest.args | 4 ++-- .../graphics-spice-timeout.xml | 18 ------------------ .../graphics-spice-timeout.x86_64-latest.xml | 17 +---------------- 3 files changed, 3 insertions(+), 36 deletions(-) diff --git a/tests/qemuxml2argvdata/graphics-spice-timeout.x86_64-latest.args b/tests/qemuxml2argvdata/graphics-spice-timeout.x86_64-latest.args index 17b49e3169..13c4c08e6f 100644 --- a/tests/qemuxml2argvdata/graphics-spice-timeout.x86_64-latest.args +++ b/tests/qemuxml2argvdata/graphics-spice-timeout.x86_64-latest.args @@ -12,11 +12,11 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-f14/.config \ -object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-f14/master-key.aes"}' \ -machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram \ -accel kvm \ --cpu core2duo,ds=on,acpi=on,ss=on,ht=on,tm=on,pbe=on,ds-cpl=on,vmx=on,est=on,tm2=on,cx16=on,xtpr=on,lahf-lm=on \ +-cpu qemu64 \ -m 1024 \ -object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \ -overcommit mem-lock=off \ --smp 2,sockets=1,dies=1,cores=2,threads=1 \ +-smp 2,sockets=2,cores=1,threads=1 \ -uuid 553effab-b5e1-2d80-dfe3-da4344826c43 \ -no-user-config \ -nodefaults \ diff --git a/tests/qemuxml2argvdata/graphics-spice-timeout.xml b/tests/qemuxml2argvdata/graphics-spice-timeout.xml index 57b48656b2..d1620b7df4 100644 --- a/tests/qemuxml2argvdata/graphics-spice-timeout.xml +++ b/tests/qemuxml2argvdata/graphics-spice-timeout.xml @@ -15,24 +15,6 @@ <apic/> <pae/> </features> - <cpu match='exact' check='none'> - <model>core2duo</model> - <vendor>Intel</vendor> - <topology sockets='1' dies='1' cores='2' threads='1'/> - <feature policy='require' name='ds'/> - <feature policy='require' name='acpi'/> - <feature policy='require' name='ss'/> - <feature policy='require' name='ht'/> - <feature policy='require' name='tm'/> - <feature policy='require' name='pbe'/> - <feature policy='require' name='ds_cpl'/> - <feature policy='require' name='vmx'/> - <feature policy='require' name='est'/> - <feature policy='require' name='tm2'/> - <feature policy='require' name='cx16'/> - <feature policy='require' name='xtpr'/> - <feature policy='require' name='lahf_lm'/> - </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> diff --git a/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml b/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml index 6f8a20950c..6f1c0a6c93 100644 --- a/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/graphics-spice-timeout.x86_64-latest.xml @@ -16,22 +16,7 @@ <pae/> </features> <cpu mode='custom' match='exact' check='none'> - <model fallback='allow'>core2duo</model> - <vendor>Intel</vendor> - <topology sockets='1' dies='1' cores='2' threads='1'/> - <feature policy='require' name='ds'/> - <feature policy='require' name='acpi'/> - <feature policy='require' name='ss'/> - <feature policy='require' name='ht'/> - <feature policy='require' name='tm'/> - <feature policy='require' name='pbe'/> - <feature policy='require' name='ds_cpl'/> - <feature policy='require' name='vmx'/> - <feature policy='require' name='est'/> - <feature policy='require' name='tm2'/> - <feature policy='require' name='cx16'/> - <feature policy='require' name='xtpr'/> - <feature policy='require' name='lahf_lm'/> + <model fallback='forbid'>qemu64</model> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> -- 2.35.1

2 1

[PATCH] vmx: Fix leak in virVMXParseEthernet
by Martin Kletzander 18 Aug '22

18 Aug '22

Commit 580538c5dd7f forgot to free switchId. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 9ad463658aa8..191f0b5e83ff 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -2920,6 +2920,7 @@ virVMXParseEthernet(virConf *conf, int controller, virDomainNetDef **def) VIR_FREE(address); VIR_FREE(virtualDev); VIR_FREE(vnet); + VIR_FREE(switchId); return result; } -- 2.37.2

2 1

[PATCH] news: Mention esx support for new interface types
by Martin Kletzander 18 Aug '22

18 Aug '22

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- NEWS.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 548828c60d72..468b41c1fd9a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -24,6 +24,11 @@ v8.7.0 (unreleased) * **Improvements** + * esx: Domain XMLs can now be dumped for VMs with two new interface types + + One is when the interface is not connected anywhere `type='dummy'` and one + when it is connected to VMWare Distributed Switch `type='vds'`. + * **Bug fixes** -- 2.37.2

2 1

slow live migration ram
by Ignazio Cassano 18 Aug '22

18 Aug '22

Hello, I am using openstack rdo with kvm libvirt. Live migration is very slow when the vm is using ram intensively. If I migrate a vm that has been running on a host for a few days, it takes several minutes to migrate the memory. After the first migration, I immediately try another one on the same vm, it takes very little. I think it's due to the fragmentation of the pages: is there any remedy? Thanks Ignazio

1 0

[PATCH v4 0/3] qemu: add an API for "query-stats" QMP command
by Amneesh Singh 18 Aug '22

18 Aug '22

QEMU is gaining introspectable statistics which can be queried via the "query-stats" QMP command. This patchset aims to add an API for the same. The returned JSON for "query-stats" is an array of objects containing their own respective array of statistics. Patch 1 adds the API for "query-stats" and a function to deserialize the returned objects into respective hashtables. Patch 2 adds the "query-stats" to QEMU capabilities. Patch 3 uses the API to query the halt poll success time and the halt poll failure time. v3 -> v4 ======== Some changes based on past reviews by Mr. Martin and me [1/3]: - - clean up qemuMonitorQueryStatsProviderNew. - make relevant checks/changes to support the change above. - do NOT return the GPtrArray, instead just return the json object. (this helps retain the non-stat info returned which will be useful in the future patches). - add a function which deserializes value associated with the "stats" key in the JSON object (one of the objects returned in the JSON array above) into a GHashTable. [2/3]: - add a flag to for the capability in tests. [3/3]: - use a helper function to make things cleaner. v2 -> v3 ======== Sorry for the late patchset, I was under the impression I had sent it on Monday but apparently, I did not. [1/3]: - use a single enum for all the statistics. - use QEMU_MONITOR_QUERY_STATS_NAME_LAST as the sentinel value for the provider constructor. - relevant changes to enum values. [2/3]: - fix comment spacing [3/3] - better checks v1 -> v2 ======== I have been tinkering with the v1 patchset and have rewrote the v2 patches a couple of times. I believe the current patchset is still not perfect and would appreciate some reviews. I have another patch or two written but they do not make any significant changes to the current patchset. [1/3]: - use virBitmap instead of an array of strings for statistics. - add enums for the stat names and add qemuMonitorQueryStatsNameTypeToString to switch between the "ToString" functions based on the target type. - change qemuMonitorQueryStatsProviderNew to a variadic function that takes stat enum values with the sentinel value being -1. [2/3]: - No changes [3/3]: - Add relevant monitor related checks to check if the domain is active. - Acquire and release qemuMonitorObj lock before and after calling qemuMonitorQueryStats respectively. - Add the check for privileged access. Relevant QEMU patches can be found here: https://lore.kernel.org/all/20220530150714.756954-1-pbonzini@redhat.com/ This patchset is part of the 2022 GSOC contributor project. Amneesh Singh (3): qemu_monitor: add qemuMonitorQueryStats qemu_capabilities: add "query-stats" QMP command to the QEMU capabilities qemu_driver: use qemuMonitorQueryStats to extract halt poll time src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_driver.c | 81 +++++++++++- src/qemu/qemu_monitor.c | 117 ++++++++++++++++++ src/qemu/qemu_monitor.h | 48 +++++++ src/qemu/qemu_monitor_json.c | 91 ++++++++++++++ src/qemu/qemu_monitor_json.h | 6 + .../caps_7.1.0.x86_64.xml | 1 + 8 files changed, 345 insertions(+), 6 deletions(-) -- 2.37.1

2 6

[libvirt PATCH 0/2] tests: Fix qemuxml2argvtest failure on macOS 12
by Andrea Bolognani 18 Aug '22

18 Aug '22

As reported in https://listman.redhat.com/archives/libvir-list/2022-May/230762.html I'm still unclear on why this worked with all versions of macOS until 12, but the fix feels reasonable enough and I can't really justify digging much further. Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/615807379 macOS 12 job: https://gitlab.com/abologna/libvirt/-/jobs/2895958597 Andrea Bolognani (2): util: Preserve macOS dyld environment by default tests: Reset macOS dyld environment src/util/vircommand.c | 2 ++ tests/qemuxml2argvtest.c | 2 ++ 2 files changed, 4 insertions(+) -- 2.37.2

2 3

[PATCH] RFC: char: deprecate usage of bidirectional pipe
by marcandre.lureau＠redhat.com 16 Aug '22

16 Aug '22

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> As Ed Swierk explained back in 2006: https://lists.nongnu.org/archive/html/qemu-devel/2006-12/msg00160.html "When qemu writes into the pipe, it immediately reads back what it just wrote and treats it as a monitor command, endlessly breathing its own exhaust." This is similarly confusing when using the chardev with a serial device, as reported in https://bugzilla.redhat.com/show_bug.cgi?id=2106975. It seems we have kept the support for bidirectional pipes for historical reasons and odd systems, however it's not documented in qemu -chardev options. I suggest to stop supporting it, for portability reasons. Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com> --- docs/about/deprecated.rst | 6 ++++++ chardev/char-pipe.c | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7ee26626d5cf..dd5ca30d527b 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -45,6 +45,12 @@ transmit audio through the VNC protocol. ``tty`` and ``parport`` are aliases that will be removed. Instead, the actual backend names ``serial`` and ``parallel`` should be used. +``-chardev pipe`` support for bidirectional pipes (since 7.1) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +For portability reasons, the support for bidirectional ``pipe`` will +be removed. Instead, use ``file.in`` & ``file.out`` unidirectional pipes. + Short-form boolean options (since 6.0) '''''''''''''''''''''''''''''''''''''' diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c index 66d3b8509183..7db963035e7d 100644 --- a/chardev/char-pipe.c +++ b/chardev/char-pipe.c @@ -27,6 +27,7 @@ #include "qemu/main-loop.h" #include "qemu/module.h" #include "qemu/option.h" +#include "qemu/error-report.h" #include "chardev/char.h" #ifdef _WIN32 @@ -142,6 +143,9 @@ static void qemu_chr_open_pipe(Chardev *chr, if (fd_out >= 0) { close(fd_out); } + warn_report("Support for bidirectional pipe is deprecated,"); + warn_report("please use portable one-way pipes instead (%s.in & %s.out).", + filename, filename); TFR(fd_in = fd_out = qemu_open_old(filename, O_RDWR | O_BINARY)); if (fd_in < 0) { error_setg_file_open(errp, errno, filename); -- 2.37.0.rc0

4 4

[PATCH] qemu_tpm: Don't crash if qemuTPMPcrBankBitmapToStr(NULL)
by Michal Privoznik 15 Aug '22

15 Aug '22

Historically, the tpm->data.emulator.activePcrBanks member was an unsigned int but since it was used as a bitmap it was converted to virBitmap type instead. Now, the virBitmap is allocated inside of virDomainTPMDefParseXML() but only if <activePcrBanks/> was found with at last one child element. Otherwise it stays NULL. Fast forward to starting a domain with TPM 2.0 and no <activePcrBanks/> configured. Eventually, qemuTPMEmulatorBuildCommand() is called, which subsequently calls qemuTPMEmulatorReconfigure() and finally qemuTPMPcrBankBitmapToStr() passing the NULL value. Before rewrite to virBitmap this function would return NULL for empty activePcrBanks but now, well, now it crashes. Fixes: 52c7c31c8038aa31d502f59a40e4fb4ba9f61113 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_tpm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index c08b0851da..584c787b70 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -449,6 +449,9 @@ qemuTPMPcrBankBitmapToStr(virBitmap *activePcrBanks) g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER; ssize_t bank = -1; + if (!activePcrBanks) + return NULL; + while ((bank = virBitmapNextSetBit(activePcrBanks, bank)) > -1) virBufferAsprintf(&buf, "%s,", virDomainTPMPcrBankTypeToString(bank)); -- 2.35.1

2 1

[PATCH 00/11] Dirty page rate limit support
by huangy81＠chinatelecom.cn 14 Aug '22

14 Aug '22

From: Hyman Huang(黄勇) <huangy81(a)chinatelecom.cn> Qemu introduced dirty page rate limit feature in 7.1.0, see the details in the following link: https://lore.kernel.org/qemu-devel/cover.1656177590.git.huangy81@chinatelec… So may be it's the right time to enabling this feature in libvirt meanwhile so that upper user can play with it. Expecting the upper app can use this feature to do a vcpu Qos or whatever else. This patch add 2 new apis to implement dirty page rate limit: 1. virDomainSetVcpuDirtyLimit, which set vcpu dirty page rate limit. virsh command 'vcpudirtylimit' also implemented correspondingly. 2. virDomainCancelVcpuDirtyLimit, which cancel vcpu dirty page rate limit. 'cancel' option was introduced to 'vcpudirtylimit' to cancel the limit correspondingly. In addition, function 'qemuMonitorQueryVcpuDirtyLimit' was implemented to query dirty page rate limit, virsh command 'vcpuinfo' was extended so that user can query dirty page rate limit info via 'vcpuinfo'. This series make main modifications as the following: - introduce QEMU_CAPS_VCPU_DIRTY_LIMIT capability so that libvirt can probe before using dirty page rate limit feature. - implement virsh command 'vcpudirtylimit' to set/cancel dirty page rate limit. - extend vcpuinfo api so that it can display dirtylimit info. - document dirty page rate limit feature. Please review, thanks! Best regards! *** BLURB HERE *** Hyman Huang(黄勇) (11): qemu_capabilities: Introduce QEMU_CAPS_VCPU_DIRTY_LIMIT capability libvirt: Add virDomainSetVcpuDirtyLimit API qemu_driver: Implement qemuDomainSetVcpuDirtyLimit virsh: Introduce vcpudirtylimit api qemu_monitor: Implement qemuMonitorQueryVcpuDirtyLimit qemu_driver: Extend qemuDomainGetVcpus for dirtylimit virsh: Extend vcpuinfo api to display dirtylimit info libvirt: Add virDomainCancelVcpuDirtyLimit API qemu_driver: Implement qemuDomainCancelVcpuDirtyLimit virsh: Add cancel option to vcpudirtylimit api NEWS: Document dirty page rate limit APIs NEWS.rst | 13 ++ include/libvirt/libvirt-domain.h | 22 ++++ src/driver-hypervisor.h | 13 ++ src/libvirt-domain.c | 95 +++++++++++++++ src/libvirt_public.syms | 6 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_driver.c | 146 +++++++++++++++++++++++ src/qemu/qemu_monitor.c | 35 ++++++ src/qemu/qemu_monitor.h | 26 ++++ src/qemu/qemu_monitor_json.c | 137 +++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 13 ++ src/remote/remote_daemon_dispatch.c | 2 + src/remote/remote_driver.c | 4 + src/remote/remote_protocol.x | 30 ++++- src/remote_protocol-structs | 13 ++ tests/qemucapabilitiesdata/caps_7.1.0.x86_64.xml | 1 + tools/virsh-domain.c | 112 +++++++++++++++++ 18 files changed, 673 insertions(+), 2 deletions(-) -- 1.8.3.1

1 11

[PATCH for-7.1?] Fix some typos in documentation (most of them found by codespell)
by Stefan Weil 12 Aug '22

12 Aug '22

Signed-off-by: Stefan Weil <sw(a)weilnetz.de> --- docs/about/deprecated.rst | 2 +- docs/specs/acpi_erst.rst | 4 ++-- docs/system/devices/canokey.rst | 8 ++++---- docs/system/devices/cxl.rst | 12 ++++++------ 4 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7ee26626d5..91b03115ee 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -297,7 +297,7 @@ by using ``-machine graphics=off``. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64 -identifer that is not globally unique. If an EUI-64 identifer is required, the +identifier that is not globally unique. If an EUI-64 identifier is required, the user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``. ``-device nvme,use-intel-id=on|off`` (since 7.1) diff --git a/docs/specs/acpi_erst.rst b/docs/specs/acpi_erst.rst index a8a9d22d25..2339b60ad7 100644 --- a/docs/specs/acpi_erst.rst +++ b/docs/specs/acpi_erst.rst @@ -108,7 +108,7 @@ Slot 0 contains a backend storage header that identifies the contents as ERST and also facilitates efficient access to the records. Depending upon the size of the backend storage, additional slots will be designated to be a part of the slot 0 header. For example, at 8KiB, -the slot 0 header can accomodate 1021 records. Thus a storage size +the slot 0 header can accommodate 1021 records. Thus a storage size of 8MiB (8KiB * 1024) requires an additional slot for use by the header. In this scenario, slot 0 and slot 1 form the backend storage header, and records can be stored starting at slot 2. @@ -196,5 +196,5 @@ References [2] "Unified Extensible Firmware Interface Specification", version 2.1, October 2008. -[3] "Windows Hardware Error Architecture", specfically +[3] "Windows Hardware Error Architecture", specifically "Error Record Persistence Mechanism". diff --git a/docs/system/devices/canokey.rst b/docs/system/devices/canokey.rst index c2c58ae3e7..cfa6186e48 100644 --- a/docs/system/devices/canokey.rst +++ b/docs/system/devices/canokey.rst @@ -28,9 +28,9 @@ With the same software configuration as a hardware key, the guest OS can use all the functionalities of a secure key as if there was actually an hardware key plugged in. -CanoKey QEMU provides much convenience for debuging: +CanoKey QEMU provides much convenience for debugging: -* libcanokey-qemu supports debuging output thus developers can +* libcanokey-qemu supports debugging output thus developers can inspect what happens inside a secure key * CanoKey QEMU supports trace event thus event * QEMU USB stack supports pcap thus USB packet between the guest @@ -102,8 +102,8 @@ and find CanoKey QEMU there: You may setup the key as guided in [6]_. The console for the key is at [7]_. -Debuging -======== +Debugging +========= CanoKey QEMU consists of two parts, ``libcanokey-qemu.so`` and ``canokey.c``, the latter of which resides in QEMU. The former provides core functionality diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst index 36031325cc..f25783a4ec 100644 --- a/docs/system/devices/cxl.rst +++ b/docs/system/devices/cxl.rst @@ -83,7 +83,7 @@ CXL Fixed Memory Windows (CFMW) A CFMW consists of a particular range of Host Physical Address space which is routed to particular CXL Host Bridges. At time of generic software initialization it will have a particularly interleaving -configuration and associated Quality of Serice Throtling Group (QTG). +configuration and associated Quality of Service Throttling Group (QTG). This information is available to system software, when making decisions about how to configure interleave across available CXL memory devices. It is provide as CFMW Structures (CFMWS) in @@ -98,7 +98,7 @@ specification defined register interface called CXL Host Bridge Component Registers (CHBCR). The location of this CHBCR MMIO space is described to system software via a CXL Host Bridge Structure (CHBS) in the CEDT ACPI table. The actual interfaces -are identical to those used for other parts of the CXL heirarchy +are identical to those used for other parts of the CXL hierarchy as CXL Component Registers in PCI BARs. Interfaces provided include: @@ -143,7 +143,7 @@ CXL Memory Devices - Type 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ CXL type 3 devices use a PCI class code and are intended to be supported by a generic operating system driver. They have HDM decoders -though in these EP devices, the decoder is reponsible not for +though in these EP devices, the decoder is responsible not for routing but for translation of the incoming host physical address (HPA) into a Device Physical Address (DPA). @@ -209,7 +209,7 @@ Notes: ranges of the system physical address map. Each CFMW has particular interleave setup across the CXL Host Bridges (HB) CFMW0 provides uninterleaved access to HB0, CFW2 provides - uninterleaved acess to HB1. CFW1 provides interleaved memory access + uninterleaved access to HB1. CFW1 provides interleaved memory access across HB0 and HB1. (2) **Two CXL Host Bridges**. Each of these has 2 CXL Root Ports and @@ -282,7 +282,7 @@ Example topology involving a switch:: --------------------------------------------------- | Switch 0 USP as PCI 0d:00.0 | | USP has HDM decoder which direct traffic to | - | appropiate downstream port | + | appropriate downstream port | | Switch BUS appears as 0e | |x__________________________________________________| | | | | @@ -366,7 +366,7 @@ An example of 4 devices below a switch suitable for 1, 2 or 4 way interleave:: Kernel Configuration Options ---------------------------- -In Linux 5.18 the followings options are necessary to make use of +In Linux 5.18 the following options are necessary to make use of OS management of CXL memory devices as described here. * CONFIG_CXL_BUS -- 2.30.2

3 3

[PATCH 0/3] schema: Some fixes and maxphyaddr support in hostcpu
by Jim Fehlig 12 Aug '22

12 Aug '22

Inspired by Tim's patch to fix my earlier omission https://listman.redhat.com/archives/libvir-list/2022-August/233624.html Jim Fehlig (3): schema: Remove optional nesting in hostcpu rng schema: Don't enforce ordering of hostcpu capabilities elements schema: Add maxphysaddr element to hostcpu src/conf/schemas/cputypes.rng | 47 +++++++++++++----------- tests/capabilityschemadata/caps-test.xml | 2 + 2 files changed, 28 insertions(+), 21 deletions(-) -- 2.37.1

2 4