- Devel - libvirt List Archives

[libvirt PATCH] util: Fix getting CPU frequency on Apple Silicon
by Andrea Bolognani 14 Feb '22

14 Feb '22

The hw.cpufrequency sysctl, which we use to obtain the CPU frequency on macOS, is not available when running on Apple Silicon, and as a consequence we currently report an error whenever such information is requested. The virNodeInfo.mhz field, where the CPU frequency gets stored, is documented as being zero when the information could not be obtained, and we already do that for Linux on aarch64. Extend this behavior to macOS on Apple Silicon. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/util/virhostcpu.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index a07c00a0e9..011ef8a153 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -928,8 +928,14 @@ virHostCPUGetInfo(virArch hostarch G_GNUC_UNUSED, *mhz = cpu_freq; # else if (sysctlbyname("hw.cpufrequency", &cpu_freq, &cpu_freq_len, NULL, 0) < 0) { - virReportSystemError(errno, "%s", _("cannot obtain CPU freq")); - return -1; + if (errno == ENOENT) { + /* The hw.cpufrequency sysctl is not implemented on Apple Silicon. + * In that case, we report 0 instead of erroring out */ + cpu_freq = 0; + } else { + virReportSystemError(errno, "%s", _("cannot obtain CPU freq")); + return -1; + } } *mhz = cpu_freq / 1000000; -- 2.34.1

3 4

[PATCH 00/27] qemu: Fix chardev hot(un)plug issues and sanitize use of /dev/fdset/N
by Peter Krempa 14 Feb '22

14 Feb '22

This series addresses the following issues: - hot-unplug of chardevs leaks the FDset in qemu - hot-plug of chardev doesn't use virtlogd even when configured - the name of the FD used for vdpa doesn't really tie it to the device There's also improvement in the common code handling the FD passing and few other drive-by fixes. Peter Krempa (27): scripts/moc-noinline: Use full name of the required annotation in error message qemuProcessPrepareHostBackendChardevFileHelper: Always use FD passing qemuProcessPrepareHostBackendChardev: Drop unneeded arguments qemuMonitorJSONQueryFdsetsParse: Don't check value passed to g_strdup qemuMonitorRemoveFdset: Convert @fdset to unsigned int to avoid error qemu: monitor: Make 'id' in 'struct _qemuMonitorFdsetInfo' unsigned qemu: domain: Move and unexport 'qemuDomainStorageIdReset' qemu: domain: Add helper for generating 'fdset' ids for VM startup qemu: Introduce helper functions for passing FDs to qemu qemuBuildInterfaceCommandLine: Use qemuFDPass for the vdpa fd qemu: hotplug: Extract code for unplugging fdsets qemuHotplugRemoveFDSet: Prepare for proper FD unplug handling qemuBuildInterfaceCommandLine: Use new pattern for naming the VDPA fdset qemu: Rewrite chardev startup code to use qemuFDPass qemuDomainRemoveChrDevice: Detach fdset after chardev hot-unplug qemumonitorjsontest: chardev: Remove need to allow unused commands qemumonitorjsontest: Refactor chardev hotplug testing qemuMonitorJSONTestAttachChardev: Add test for TLS-secured TCP chardev qemuMonitorJSONTestAttachChardev: Add logfile to some tests qemuMonitorJSONAttachCharDevGetProps: Properly handle private data tests: Move testPrepareHostBackendChardevOne into test utils qemuMonitorJSONTestAttachChardev: Add tests for FD passing of file backend qemu: process: Add a hotplug version of qemuProcessPrepareHostBackendChardev qemu: Honour 'virtlogd' use when hotplugging chardevs virTPMCreateCancelPath: Refactor value returning qemuBuildTPMOpenBackendFDs: Construct 'cancel_path' internally qemuBuildTPMCommandLine: Use 'qemuPassFD' infrastructure po/POTFILES.in | 1 + scripts/mock-noinline.py | 2 +- src/qemu/meson.build | 1 + src/qemu/qemu_command.c | 260 +++++---------- src/qemu/qemu_command.h | 4 +- src/qemu/qemu_domain.c | 94 +++--- src/qemu/qemu_domain.h | 13 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_fd.c | 296 ++++++++++++++++++ src/qemu/qemu_fd.h | 56 ++++ src/qemu/qemu_hotplug.c | 100 ++++-- src/qemu/qemu_hotplug.h | 2 +- src/qemu/qemu_monitor.c | 14 +- src/qemu/qemu_monitor.h | 4 +- src/qemu/qemu_monitor_json.c | 82 +++-- src/qemu/qemu_monitor_json.h | 2 +- src/qemu/qemu_process.c | 102 ++++-- src/qemu/qemu_process.h | 6 + src/util/virtpm.c | 13 +- tests/qemuhotplugmock.c | 11 + tests/qemuhotplugtest.c | 6 +- tests/qemumonitorjsontest.c | 253 +++++++++------ .../qemuxml2argvdata/aarch64-pci-serial.args | 3 +- .../name-escape.x86_64-2.11.0.args | 3 +- .../name-escape.x86_64-latest.args | 4 +- .../net-vdpa.x86_64-latest.args | 4 +- .../qemuxml2argvdata/serial-file-chardev.args | 3 +- .../serial-file-chardev.x86_64-latest.args | 4 +- tests/qemuxml2argvdata/serial-file-log.args | 4 +- .../serial-file-log.x86_64-latest.args | 6 +- .../qemuxml2argvdata/serial-many-chardev.args | 3 +- .../serial-many-chardev.x86_64-latest.args | 4 +- .../tpm-passthrough-crb.x86_64-latest.args | 6 +- .../tpm-passthrough.x86_64-latest.args | 6 +- tests/qemuxml2argvmock.c | 1 - tests/qemuxml2argvtest.c | 87 +---- tests/testutilsqemu.c | 106 +++++++ tests/testutilsqemu.h | 3 + 38 files changed, 1011 insertions(+), 561 deletions(-) create mode 100644 src/qemu/qemu_fd.c create mode 100644 src/qemu/qemu_fd.h -- 2.34.1

2 58

[libvirt PATCH] tests: Use freecon in testSELinuxCheckLabels
by Jiri Denemark 11 Feb '22

11 Feb '22

This partially reverts commit 0fc4a43d248b86fd54ad7323beb66faec8c1043c. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tests/securityselinuxlabeltest.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/securityselinuxlabeltest.c b/tests/securityselinuxlabeltest.c index dfe9d38d34..83532d8090 100644 --- a/tests/securityselinuxlabeltest.c +++ b/tests/securityselinuxlabeltest.c @@ -230,7 +230,7 @@ testSELinuxCheckLabels(testSELinuxFile *files, size_t nfiles) size_t i; for (i = 0; i < nfiles; i++) { - g_autofree char *ctx = NULL; + char *ctx = NULL; if (getfilecon(files[i].file, &ctx) < 0) { if (errno == ENODATA) { /* nothing to do */ @@ -247,8 +247,10 @@ testSELinuxCheckLabels(testSELinuxFile *files, size_t nfiles) virReportError(VIR_ERR_INTERNAL_ERROR, "File %s context '%s' did not match expected '%s'", files[i].file, ctx, files[i].context); + freecon(ctx); return -1; } + freecon(ctx); } return 0; } -- 2.35.0

3 4

[libvirt PATCH] conf: Initialize devAddr in virNodeDeviceGetPCIVPDDynamicCap
by Jiri Denemark 11 Feb '22

11 Feb '22

Otherwise devAddr.multi would be uninitialized. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/conf/node_device_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 61c8715037..eaa42c05ee 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -3018,7 +3018,7 @@ static int virNodeDeviceGetPCIVPDDynamicCap(virNodeDevCapPCIDev *devCapPCIDev) { g_autoptr(virPCIDevice) pciDev = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = {0}; g_autoptr(virPCIVPDResource) res = NULL; devAddr.domain = devCapPCIDev->domain; -- 2.35.0

2 2

[PATCH] src: Initialize stack allocated virPCIDeviceAddress variables
by Michal Privoznik 11 Feb '22

11 Feb '22

There are few places where a virPCIDeviceAddress typed variable is allocated on the stack but it's not initialized. This can lead to random values of its members which in turn can lead to a random behaviour. Generated with help of the following spatch: @@ identifier I; @@ - virPCIDeviceAddress I; + virPCIDeviceAddress I = { 0 }; And then fixing bhyveAssignDevicePCISlots() which does declare the variable and then explicitly zero it by calling memset() only to set a specific member afterwards. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/bhyve/bhyve_device.c | 5 +---- src/conf/domain_addr.c | 2 +- src/conf/node_device_conf.c | 4 ++-- src/hypervisor/domain_driver.c | 6 +++--- src/node_device/node_device_udev.c | 2 +- src/qemu/qemu_domain_address.c | 4 ++-- src/util/virpci.c | 2 +- 7 files changed, 11 insertions(+), 14 deletions(-) diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c index 36b93c0d4c..5654028ca5 100644 --- a/src/bhyve/bhyve_device.c +++ b/src/bhyve/bhyve_device.c @@ -83,10 +83,7 @@ bhyveAssignDevicePCISlots(virDomainDef *def, virDomainPCIAddressSet *addrs) { size_t i; - virPCIDeviceAddress lpc_addr; - - memset(&lpc_addr, 0, sizeof(lpc_addr)); - lpc_addr.slot = 0x1; + virPCIDeviceAddress lpc_addr = { .slot = 0x1 }; /* If the user didn't explicitly specify slot 1 for some of the devices, reserve it for LPC, even if there's no LPC device configured. diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c index 49745ba881..49ca775a52 100644 --- a/src/conf/domain_addr.c +++ b/src/conf/domain_addr.c @@ -1181,7 +1181,7 @@ virDomainPCIAddressReserveNextAddr(virDomainPCIAddressSet *addrs, virDomainPCIConnectFlags flags, int function) { - virPCIDeviceAddress addr; + virPCIDeviceAddress addr = { 0 }; if (virDomainPCIAddressGetNextAddr(addrs, &addr, flags, dev->isolationGroup, function) < 0) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 61c8715037..8b20a7bee9 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -2947,7 +2947,7 @@ virNodeDeviceGetPCIIOMMUGroupCaps(virNodeDevCapPCIDev *pci_dev) { size_t i; int tmpGroup; - virPCIDeviceAddress addr; + virPCIDeviceAddress addr = { 0 }; /* this could be a refresh, so clear out the old data */ for (i = 0; i < pci_dev->nIommuGroupDevices; i++) @@ -3018,7 +3018,7 @@ static int virNodeDeviceGetPCIVPDDynamicCap(virNodeDevCapPCIDev *devCapPCIDev) { g_autoptr(virPCIDevice) pciDev = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = { 0 }; g_autoptr(virPCIVPDResource) res = NULL; devAddr.domain = devCapPCIDev->domain; diff --git a/src/hypervisor/domain_driver.c b/src/hypervisor/domain_driver.c index 2083f06287..bb1da7ac6b 100644 --- a/src/hypervisor/domain_driver.c +++ b/src/hypervisor/domain_driver.c @@ -375,7 +375,7 @@ virDomainDriverNodeDeviceReset(virNodeDevicePtr dev, virHostdevManager *hostdevMgr) { g_autoptr(virPCIDevice) pci = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = { 0 }; g_autoptr(virNodeDeviceDef) def = NULL; g_autofree char *xml = NULL; g_autoptr(virConnect) nodeconn = NULL; @@ -421,7 +421,7 @@ virDomainDriverNodeDeviceReAttach(virNodeDevicePtr dev, virHostdevManager *hostdevMgr) { g_autoptr(virPCIDevice) pci = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = { 0 }; g_autoptr(virNodeDeviceDef) def = NULL; g_autofree char *xml = NULL; g_autoptr(virConnect) nodeconn = NULL; @@ -466,7 +466,7 @@ virDomainDriverNodeDeviceDetachFlags(virNodeDevicePtr dev, const char *driverName) { g_autoptr(virPCIDevice) pci = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = { 0 }; g_autoptr(virNodeDeviceDef) def = NULL; g_autofree char *xml = NULL; g_autoptr(virConnect) nodeconn = NULL; diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 3d5e25424a..b0a5e6302c 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -366,7 +366,7 @@ udevProcessPCI(struct udev_device *device, virNodeDevCapPCIDev *pci_dev = &def->caps->data.pci_dev; virPCIEDeviceInfo *pci_express = NULL; virPCIDevice *pciDev = NULL; - virPCIDeviceAddress devAddr; + virPCIDeviceAddress devAddr = { 0 }; int ret = -1; char *p; bool privileged = false; diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 4e7095d3a7..dd0680f57f 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -1743,7 +1743,7 @@ qemuDomainValidateDevicePCISlotsPIIX3(virDomainDef *def, virDomainPCIAddressSet *addrs) { size_t i; - virPCIDeviceAddress tmp_addr; + virPCIDeviceAddress tmp_addr = { 0 }; g_autofree char *addrStr = NULL; virDomainPCIConnectFlags flags = (VIR_PCI_CONNECT_AUTOASSIGN | VIR_PCI_CONNECT_TYPE_PCI_DEVICE); @@ -1853,7 +1853,7 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDef *def, virDomainPCIAddressSet *addrs) { size_t i; - virPCIDeviceAddress tmp_addr; + virPCIDeviceAddress tmp_addr = { 0 }; g_autofree char *addrStr = NULL; virDomainPCIConnectFlags flags = VIR_PCI_CONNECT_TYPE_PCIE_DEVICE; diff --git a/src/util/virpci.c b/src/util/virpci.c index adc255f438..d141fde814 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -1865,7 +1865,7 @@ virPCIDeviceAddressIOMMUGroupIterate(virPCIDeviceAddress *orig, } while ((direrr = virDirRead(groupDir, &ent, groupPath)) > 0) { - virPCIDeviceAddress newDev; + virPCIDeviceAddress newDev = { 0 }; if (virPCIDeviceAddressParse(ent->d_name, &newDev) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, -- 2.34.1

2 1

[libvirt PATCH v2 0/2] qemu_migration_cookie: Properly fetch cert DN
by Jiri Denemark 11 Feb '22

11 Feb '22

Jiri Denemark (2): qemu_migration_cookie: Rename ret in qemuDomainExtractTLSSubject qemu_migration_cookie: Properly fetch cert DN src/qemu/qemu_migration_cookie.c | 34 ++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 13 deletions(-) -- 2.35.0

2 3

[libvirt PATCH] conf: Avoid NULL-dereference in virDomainObjGetMessages
by Jiri Denemark 11 Feb '22

11 Feb '22

All callers currently guarantee flags passed to virDomainObjGetMessages are either zero or contain at least one of the supported flags. But it doesn't mean we should not check for the possibility an unknown flag was the only one passed to virDomainObjGetMessages. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/conf/domain_conf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index ab8f2a52cc..093b719b2c 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -31472,7 +31472,8 @@ virDomainObjGetMessages(virDomainObj *vm, } } - (*msgs)[nmsgs] = NULL; + if (*msgs) + (*msgs)[nmsgs] = NULL; rv = nmsgs; -- 2.35.0

2 1

[PATCH v2 0/5] More reset nvram fixes
by Michal Privoznik 11 Feb '22

11 Feb '22

v2 of: https://listman.redhat.com/archives/libvir-list/2022-February/msg00330.html I've pushed patches 1/5 and 2/5 from the original patchset because they were independent. diff to v1: - Reworked virFileRewrite() so that it's callback's responsibility to report error, - More trivial cleanups (VIR_AUTOCLOSE, drop 'cleanup' label) Michal Prívozník (5): virFileRewrite: Allow setting owner virFileRewrite: Move error reporting into callback qemuPrepareNVRAM: Us virFileRewrite() to write NVRAM qemuPrepareNVRAM: Switch to VIR_AUTOCLOSE qemuPrepareNVRAM: Drop cleanup label src/qemu/qemu_process.c | 124 ++++++++++++++++------------------------ src/util/virfile.c | 44 +++++++++++--- src/util/virfile.h | 5 +- src/util/virxml.c | 22 +++++-- 4 files changed, 104 insertions(+), 91 deletions(-) -- 2.34.1

2 9

[libvirt PATCH 0/2] qemu_migration_cookie: Properly fetch cert DN
by Jiri Denemark 11 Feb '22

11 Feb '22

Jiri Denemark (2): qemu_migration_cookie: Rename ret in qemuDomainExtractTLSSubject qemu_migration_cookie: Properly fetch cert DN src/qemu/qemu_migration_cookie.c | 35 +++++++++++++++++++------------- 1 file changed, 21 insertions(+), 14 deletions(-) -- 2.35.1

2 5

Edge cases around writable firmware and/or NVRAM cleanup
by Daniel P. Berrangé 11 Feb '22

11 Feb '22

The typical scenario for UEFI is that we have readonly firmware with separate NVRAM <loader readonly="on">/some/ovmf/path_CODE.fd</loader> <nvram template="/some/ovmf/path_VARS.fd"/> In this case we of course copy path_VARS.fd into a private file path we invent under /var/lib. The user can give an explicit NVRAM path too: <loader readonly="on">/some/ovmf/path_CODE.fd</loader> <nvram>/var/lib/libvirt/images/guest_vars.fd</nvram> If template isn't set, and can't be identified from path_CODE.fd automatically, then the NVRAM file must exist ahead of time. When undefining a VM's persistent config we refuse to allow it if an NVRAM exists, unless UNDEFINE_NVRAM is set which causes it to be deleted. Alternatively KEEP_NVRAM can cause the NVRAM to be left behind. I've always felt this is quite dubious because we happily let the VM be undefined with disks still existing, or TPM state still exist, or any number of files remaining. With that in mind, we have other configurations that are possible. For example, a single writable loader file, either implicitly: <loader>/var/lib/libvirt/images/guest.fd</loader> or explicitly: <loader readonly="off">/var/lib/libvirt/images/guest.fd</loader> In both cases this guest.fd must be pre-populated by the mgt apps since we don't initialize it from any template. We also dont place any restrictions on the undefine step when using a writable loader. This config is fairly sane in that yu can build EDK2 with both CODE and VARs in one file. This makes sense for a public cloud scenario if the user is allowed to bring along their own firmware, as there's no benefit to splitting CODE+VARs if the firmware is just used for a single VM. Building on that though we allow a somewhuat questionable config: <loader>/var/lib/libvirt/images/guest.fd</loader> <nvram>/var/lib/libvirt/images/guest_vars.fd</nvram> where both loader + nvram are writable. We allow 'template' to be set but we completely ignore it, since the loader is not marked read-only. THe mgmt app must pre-create both these writable files now, and undefine only complains about the nvram file. I'm wondering what, if anything, we should do in these edge cases - Allow 'template' on the <loader> element to populate a writable combined CODE+VARS image ? This would let us use a combined CODE+VARS file as a template for writable firmware. - Allow 'template' on the <nvram> element to populate a writable combined CODE+VARS image for <loader>? Takes advantage of fact that 'template' is ignored currently if <loader> is not read-only. That rationale is that <nvram> element doesn't imply that the NVRAM has to be separate, just that there is NVRAM and the primary writable loader provides that. - Or reject 'template' on <nvram> element if <loader> is writable rather than ignoring it ? Mutually exclusive with previous point - Make undefine use NVRAM flags to apply to writable <loader> too ? That could be considwered a behaviour change for existing users though, unless we only do that when support use of a 'template' for the <loader>. - Reject the wierd writable loader + writable NVRAM config ? I can't imagine why we need this, but QEMU allows it, and blocking it would be a behavioural change Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0