- Devel - libvirt List Archives

[PATCH] nodedev: udev: Hook up virFileWaitForExist to address uevent, race of pci device
by Guoyi Tu 06 Feb '25

06 Feb '25

this commit addresses the same issue that as commit 1af45804 does. the following message is copying from that commit: If we find ourselves in the situation that the 'add' uevent has been fired earlier than the sysfs tree for a device was created, we should use the best-effort approach and give kernel some predetermined amount of time, thus waiting for the attributes to be ready rather than discarding the device from our device list forever. If those don't appear in the given time frame, we need to move on, since libvirt can't wait indefinitely. Signed-off-by: Guoyi Tu <tugy(a)chinatelecom.cn> --- src/node_device/node_device_udev.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 1d8486f623..4a1786c21c 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -427,10 +427,19 @@ udevProcessPCI(virNodeDeviceDriverState *driver_state, virPCIEDeviceInfo *pci_express = NULL; virPCIDevice *pciDev = NULL; virPCIDeviceAddress devAddr = { 0 }; + g_autofree char *linkpath = NULL; int ret = -1; char *p; bool privileged = false; + linkpath = g_strdup_printf("%s/config", udev_device_get_syspath(device)); + if (virFileWaitForExists(linkpath, 10, 100) < 0) { + virReportSystemError(errno, + _("failed to wait for file '%1$s' to appear"), + linkpath); + goto cleanup; + } + VIR_WITH_MUTEX_LOCK_GUARD(&driver_state->lock) { privileged = driver_state->privileged; } -- 2.27.0 -- Guoyi

2 2

[PATCH pushed] node_device_udev: Fix build failure in ccw device code
by Peter Krempa 05 Feb '25

05 Feb '25

clang complains: ../../../libvirt/src/node_device/node_device_udev.c:1408:82: error: result of comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-unsigned-enum-zero-compare] 1408 | if ((data->ccwgroup_dev.type = virNodeDevCCWGroupCapTypeFromString(devtype)) < 0) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ 1 error generated. Fix it by adding a temporary int variable to facilitate the check before assigning to the unsigned enum value. Fixes: 985cb9c32a6 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/node_device/node_device_udev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 082f9d5cf0..94e8626aee 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1398,6 +1398,7 @@ udevProcessCCWGroup(struct udev_device *device, { const char *devtype = udev_device_get_devtype(device); virNodeDevCapData *data = &def->caps->data; + int tmp; data->ccwgroup_dev.address = virCCWDeviceAddressFromString(udev_device_get_sysname(device)); @@ -1405,9 +1406,11 @@ udevProcessCCWGroup(struct udev_device *device, udevGenerateDeviceName(device, def, NULL); - if ((data->ccwgroup_dev.type = virNodeDevCCWGroupCapTypeFromString(devtype)) < 0) + if ((tmp = virNodeDevCCWGroupCapTypeFromString(devtype)) < 0) return -1; + data->ccwgroup_dev.type = tmp; + switch (data->ccwgroup_dev.type) { case VIR_NODE_DEV_CAP_CCWGROUP_QETH_GENERIC: case VIR_NODE_DEV_CAP_CCWGROUP_QETH_LAYER2: -- 2.48.1

1 0

[PATCH] docs: fix 'virsh domstats --vcpu' measure units and descriptions
by Fabricio Duarte 05 Feb '25

05 Feb '25

The fields are in nanoseconds, not microseconds. Also fixes the description of `vcpu.<num>.wait`, as it does not actually represent the time waiting on I/O. Signed-off-by: Fabricio Duarte <fabricio.duarte.jr(a)gmail.com> --- docs/manpages/virsh.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 2e525d3fac..b0a21e019a 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2428,14 +2428,14 @@ When selecting the *--state* group the following fields are returned: * ``vcpu.<num>.state`` - state of the virtual CPU <num>, as number from virVcpuState enum * ``vcpu.<num>.time`` - virtual cpu time spent by virtual - CPU <num> (in microseconds) -* ``vcpu.<num>.wait`` - virtual cpu time spent by virtual - CPU <num> waiting on I/O (in microseconds) + CPU <num> (in nanoseconds) +* ``vcpu.<num>.wait`` - time the vCPU <num> wants to run, but the host + scheduler has something else running ahead of it (in nanoseconds) * ``vcpu.<num>.halted`` - virtual CPU <num> is halted: yes or no (may indicate the processor is idle or even disabled, depending on the architecture) * ``vcpu.<num>.delay`` - time the vCPU <num> thread was enqueued by the - host scheduler, but was waiting in the queue instead of running. + host scheduler, but was waiting in the queue instead of running (in nanoseconds). Exposed to the VM as a steal time. This group of statistics also reports additional hypervisor-originating per-vCPU -- 2.39.2

2 1

[PATCH 0/3] qemu: Fix corner case in internal inactive snapshots
by Peter Krempa 05 Feb '25

05 Feb '25

Peter Krempa (3): qemuSnapshotForEachQcow2: Don't initialize 'nrollback' qemu: process: Export qemuPrepareNVRAM for use in snapshot code qemu: snapshot: Ensure that NVRAM image exists when taking inactive internal snapshot src/qemu/qemu_process.c | 26 ++++++++++++++------------ src/qemu/qemu_process.h | 4 ++++ src/qemu/qemu_snapshot.c | 25 ++++++++++++++++++++----- 3 files changed, 38 insertions(+), 17 deletions(-) -- 2.48.1

2 4

Investigating MAC Address Conflict Resolution in libvirt: Log Analysis and Code Location Inquiry
by Xuda Zhang 05 Feb '25

05 Feb '25

Dear Team, I am reaching out regarding an issue I encountered with libvirt and MAC address conflicts. Below is a summary of the situation: 1. Initially, the vNIC's MAC address was different from the target VM's MAC address. 2. After modifying the vNIC's MAC address to match the VM's MAC address, the network was interrupted. 3. After rebooting the VM, the vNIC's MAC address was automatically modified again. I have observed the following kernel logs during this process: Dec 24 16:59:40 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 16:59:40 zstack-manager kernel: device vnic43.0 left promiscuous modeDec 24 16:59:40 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered disabled stateDec 24 17:00:11 zstack-manager kernel: device vnic43.0 entered promiscuous modeDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered blocking stateDec 24 17:00:11 zstack-manager kernel: br_enp2s0: port 14(vnic43.0) entered forwarding state I am looking to understand the underlying code that handles the automatic modification of the vNIC's MAC address after the conflict and how the network interruption occurs. Can you help direct me to the relevant code segment or provide any insights into this behavior? Thank you for your assistance. Best regards,

4 7

[PATCH 0/5] qemu: Fix handling of persistent reservations daemon with blockjobs
by Peter Krempa 05 Feb '25

05 Feb '25

See 5/5 Peter Krempa (5): qemu_hotplug.h: Reformat according to new coding style virDomainDefHasManagedPR: Consider also disk's 'mirror' chain qemu: hotplug: Export persistent reservations manager helper functions qemu: blockjob: Remove persistent reservations manager when dropping disk images qemu: Attach persistent reservations manager if block-copy target requires it src/conf/domain_conf.c | 3 + src/qemu/qemu_blockjob.c | 3 + src/qemu/qemu_driver.c | 5 ++ src/qemu/qemu_hotplug.c | 4 +- src/qemu/qemu_hotplug.h | 175 ++++++++++++++++++++++----------------- 5 files changed, 113 insertions(+), 77 deletions(-) -- 2.48.1

2 6

[PATCH 0/2] qemucapabilitiestest: Update qemu-9.2 and add qemu-10.0 caps dumps on x86_64
by Peter Krempa 05 Feb '25

05 Feb '25

Peter Krempa (2): qemucapabilitiestest: Final update for qemu-9.2 release on x86_64 qemucapabilitiestest: Add data for the qemu-10.0 dev cycle on x86_64 .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1702 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1810 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1702 + .../caps_10.0.0_x86_64.replies | 44998 ++++++++++++++++ .../caps_10.0.0_x86_64.xml | 4160 ++ .../caps_9.2.0_x86_64.replies | 14 +- .../caps_9.2.0_x86_64.xml | 12 +- 7 files changed, 54385 insertions(+), 13 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.0.0-q35.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0-tcg.x86_64.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.x86_64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_x86_64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml -- 2.48.1

2 3

[PATCH v3 00/17] hw/microblaze: Allow running cross-endian vCPUs
by Philippe Mathieu-Daudé 05 Feb '25

05 Feb '25

Missing review: 4 (new) & 10 Since v2: - Addressed Richard's review comments Since v1: - Make device endianness configurable (Edgar) - Convert more Xilinx devices - Avoid preprocessor #if (Richard) - Add R-b tags Make machines endianness-agnostic, allowing to run a big-endian vCPU on the little-endian 'qemu-system-microblazeel' binary, and a little endian one on the big-endian 'qemu-system-microblaze' binary. Tests added, following combinations covered: - little-endian vCPU using little-endian binary (in-tree) - little-endian vCPU using big-endian binary (new) - big-endian vCPU using little-endian binary (new) - big-endian vCPU using big-endian binary (in-tree) To make a target endian-agnostic we need to remove the MO_TE uses. In order to do that, we propagate the MemOp from earlier in the call stack, or we extract it from the vCPU env (on MicroBlaze the CPU endianness is exposed by the 'ENDI' bit). Next step: Look at unifying binaries. Please review, Phil. Philippe Mathieu-Daudé (17): hw/microblaze: Restrict MemoryRegionOps are implemented as 32-bit hw/microblaze: Propagate CPU endianness to microblaze_load_kernel() hw/intc/xilinx_intc: Make device endianness configurable RFC hw/net/xilinx_ethlite: Simplify by having configurable endianness RFC hw/timer/xilinx_timer: Allow down to 8-bit memory access hw/timer/xilinx_timer: Make device endianness configurable hw/char/xilinx_uartlite: Make device endianness configurable hw/ssi/xilinx_spi: Make device endianness configurable hw/ssi/xilinx_spips: Make device endianness configurable hw/arm/xlnx-zynqmp: Use &error_abort for programming errors target/microblaze: Explode MO_TExx -> MO_TE | MO_xx target/microblaze: Set MO_TE once in do_load() / do_store() target/microblaze: Introduce mo_endian() helper target/microblaze: Consider endianness while translating code hw/microblaze: Support various endianness for s3adsp1800 machines tests/functional: Explicit endianness of microblaze assets tests/functional: Add microblaze cross-endianness tests hw/microblaze/boot.h | 4 +- include/hw/ssi/xilinx_spips.h | 1 + target/microblaze/cpu.h | 7 +++ hw/arm/xilinx_zynq.c | 1 + hw/arm/xlnx-zynqmp.c | 40 +++++-------- hw/char/xilinx_uartlite.c | 31 ++++++---- hw/intc/xilinx_intc.c | 50 ++++++++++++---- hw/microblaze/boot.c | 8 +-- hw/microblaze/petalogix_ml605_mmu.c | 4 +- hw/microblaze/petalogix_s3adsp1800_mmu.c | 58 ++++++++++++++++--- hw/microblaze/xlnx-zynqmp-pmu.c | 2 +- hw/net/xilinx_ethlite.c | 42 +++++++++----- hw/ppc/virtex_ml507.c | 1 + hw/ssi/xilinx_spi.c | 24 +++++--- hw/ssi/xilinx_spips.c | 36 +++++++----- hw/timer/xilinx_timer.c | 33 +++++++---- target/microblaze/translate.c | 49 ++++++++++------ .../functional/test_microblaze_s3adsp1800.py | 27 ++++++++- .../test_microblazeel_s3adsp1800.py | 25 +++++++- 19 files changed, 309 insertions(+), 134 deletions(-) -- 2.45.2

4 27

[PATCH v2 0/8] Enable virtio-mem-ccw
by Michal Privoznik 04 Feb '25

04 Feb '25

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KA2D… diff to v1: - Previously, virtio-mem-pci wasn't supported (in fact QEMU errored out), but this changed in QEMU upstream, so this limitation is lifted. - Added a test case for virtio-mem-pci on s390x Most of the patches is ACKed already (thanks Boris and David!), only a few remain for review. Michal Prívozník (8): qemu: Do NOT autoadd NUMA node for s390 qemu_command: Use qemuBuildVirtioDevProps() to build cmd line for virtio-mem and virtio-pmem qemuxmlconftest: Introduce memory-hotplug-virtio-mem-pci-s390x.xml qemu_caps: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW qemu: Validate virtio-mem-ccw qemu: Allow virtio-mem on CCW qemuxmlconftest: Introduce memory-hotplug-virtio-mem-ccw-s390x.xml NEWS: Document virtio-mem-ccw NEWS.rst | 5 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 28 ++++++-- src/qemu/qemu_domain.c | 6 +- src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 35 ++++++++- .../caps_10.0.0_s390x.xml | 1 + ...lug-virtio-mem-ccw-s390x.s390x-latest.args | 39 ++++++++++ ...plug-virtio-mem-ccw-s390x.s390x-latest.xml | 60 ++++++++++++++++ .../memory-hotplug-virtio-mem-ccw-s390x.xml | 57 +++++++++++++++ ...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++++++++++ ...plug-virtio-mem-pci-s390x.s390x-latest.xml | 71 +++++++++++++++++++ .../memory-hotplug-virtio-mem-pci-s390x.xml | 59 +++++++++++++++ tests/qemuxmlconftest.c | 2 + 15 files changed, 399 insertions(+), 9 deletions(-) create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml -- 2.45.3

3 16

[PATCH 0/7] hw/arm/raspi4b: Add models with 4GB and 8GB of DRAM
by Philippe Mathieu-Daudé 04 Feb '25

04 Feb '25

- Deprecate the 'raspi4b' machine name, renaming it as 'raspi4b-1g' on 32-bit hosts, 'raspi4b-2g' otherwise. - Add the 'raspi4b-4g' and 'raspi4b-8g' machines, with respectively 4GB and 8GB of DRAM. Philippe Mathieu-Daudé (7): hw/arm/raspi4b: Declare machine types using DEFINE_TYPES() macro hw/arm/raspi4b: Introduce abstract raspi4-base machine type hw/arm/raspi4b: Split raspi4b_machine_class_init() in two (1g and 2g) hw/arm/raspi4b: Rename as raspi4b-1g / raspi4b-2g, deprecating old name hw/arm/raspi4b: Expose the raspi4b-1g machine on 64-bit hosts hw/arm/raspi4b: Add the raspi4b-4g machine hw/arm/raspi4b: Add the raspi4b-8g machine docs/about/deprecated.rst | 6 +++ hw/arm/raspi4b.c | 91 +++++++++++++++++++++++++++++++-------- 2 files changed, 79 insertions(+), 18 deletions(-) -- 2.47.1

5 17