- Devel - libvirt List Archives

[PATCH] libvirt-host: VIR_NODE_CPU_STATS: clarify Linux, BSD differences
by Claudio Fontana 17 Sep '25

17 Sep '25

the accounting choices are not necessarily intuitive, especially comparing Linux with BSD, so clarify the current state of things. Mark which counters are actually used on Linux and BSD, and how they are accumulated into the libvirt statistics. Signed-off-by: Claudio Fontana <cfontana(a)suse.de> --- include/libvirt/libvirt-host.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/include/libvirt/libvirt-host.h b/include/libvirt/libvirt-host.h index 398b40c35a..4d4f1c02df 100644 --- a/include/libvirt/libvirt-host.h +++ b/include/libvirt/libvirt-host.h @@ -223,6 +223,9 @@ typedef enum { * Macro for the cumulative CPU time which was spent by the kernel, * since the node booting up (in nanoseconds). * + * Linux: this statistic includes kernel + irq + softirq time. + * BSD: this statistic includes only CP_SYS. CP_INTR is accounted separately. + * * Since: 0.9.3 */ # define VIR_NODE_CPU_STATS_KERNEL "kernel" @@ -233,6 +236,8 @@ typedef enum { * The cumulative CPU time which was spent by user processes, * since the node booting up (in nanoseconds). * + * Linux, BSD: this statistic includes user + nice time. + * * Since: 0.9.3 */ # define VIR_NODE_CPU_STATS_USER "user" @@ -243,6 +248,8 @@ typedef enum { * The cumulative idle CPU time, * since the node booting up (in nanoseconds). * + * Linux, BSD + * * Since: 0.9.3 */ # define VIR_NODE_CPU_STATS_IDLE "idle" @@ -253,6 +260,8 @@ typedef enum { * The cumulative I/O wait CPU time, * since the node booting up (in nanoseconds). * + * Linux-only. + * * Since: 0.9.3 */ # define VIR_NODE_CPU_STATS_IOWAIT "iowait" @@ -263,6 +272,9 @@ typedef enum { * The cumulative interrupt CPU time, * since the node booting up (in nanoseconds). * + * BSD-only. + * Note that on Linux, interrupt CPU time is accounted as part of "kernel". + * * Since: 1.2.2 */ # define VIR_NODE_CPU_STATS_INTR "intr" @@ -273,6 +285,9 @@ typedef enum { * The cumulative CPU time spent running guest virtual CPUs, * since the node booting up (in nanoseconds). * + * Linux-only. + * Note that on BSD, guest CPU time is accounted as part of CP_SYS alias "kernel" + * * Since: 11.8.0 */ # define VIR_NODE_CPU_STATS_GUEST "guest" -- 2.35.3

1 0

Re: [PATCH v4 07/10] qmp: add chardev-resize command
by Markus Armbruster 17 Sep '25

17 Sep '25

Cc: libvirt Filip Hejsek <filip.hejsek(a)gmail.com> writes: > From: Szymon Lukasz <noh4hss(a)gmail.com> > > The managment software can use this command to notify QEMU about the > size of the terminal connected to a chardev, QEMU can then forward this > information to the guest if the chardev is connected to a virtio console > device. > > Signed-off-by: Szymon Lukasz <noh4hss(a)gmail.com> > Suggested-by: Daniel P. Berrangé <berrange(a)redhat.com> > Signed-off-by: Filip Hejsek <filip.hejsek(a)gmail.com> > --- > chardev/char.c | 14 ++++++++++++++ > qapi/char.json | 22 ++++++++++++++++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/chardev/char.c b/chardev/char.c > index b45d79cb9b57643827eb7479257fdda2cf6b0434..6e3ade98614c949be8041ec5905a490ff536dee9 100644 > --- a/chardev/char.c > +++ b/chardev/char.c > @@ -1269,6 +1269,20 @@ bool qmp_add_client_char(int fd, bool has_skipauth, bool skipauth, > return true; > } > > +void qmp_chardev_resize(const char *id, uint16_t cols, uint16_t rows, > + Error **errp) > +{ > + Chardev *chr; > + > + chr = qemu_chr_find(id); > + if (chr == NULL) { > + error_setg(errp, "Chardev '%s' not found", id); > + return; > + } > + > + qemu_chr_resize(chr, cols, rows); > +} > + > /* > * Add a timeout callback for the chardev (in milliseconds), return > * the GSource object created. Please use this to add timeout hook for > diff --git a/qapi/char.json b/qapi/char.json > index f0a53f742c8bee24c377551803a864fd36ac78cf..0a26c5eee6b71bc5de127a91b253cc69a9fe8ce6 100644 > --- a/qapi/char.json > +++ b/qapi/char.json > @@ -874,6 +874,28 @@ > { 'command': 'chardev-send-break', > 'data': { 'id': 'str' } } > > +## > +# @chardev-resize: This name doesn't tell me what is being resized. PATCH 04 uses "winsize", which is better. The (losely) related SIGWINCH suggests "window change" or "window size change". Below, you use "terminal size". > +# > +# Notifies a chardev about the current size of the terminal connected > +# to this chardev. Yes, but what is it good for? Your commit message tells: "managment software can use this command to notify QEMU about the size of the terminal connected to a chardev, QEMU can then forward this information to the guest if the chardev is connected to a virtio console device." > +# > +# @id: the chardev's ID, must exist > +# @cols: the number of columns > +# @rows: the number of rows Blank lines between the argument descriptions, bease. What's the initial size? Do we need a way to query the size? > +# > +# Since: 10.2 > +# > +# .. qmp-example:: > +# > +# -> { "execute": "chardev-resize", "arguments": { "id": "foo", "cols": 80, "rows": 24 } } > +# <- { "return": {} } > +## > +{ 'command': 'chardev-resize', > + 'data': { 'id': 'str', > + 'cols': 'uint16', > + 'rows': 'uint16' } } > + > ## > # @VSERPORT_CHANGE: > #

2 6

Re: [PATCH 02/33] vhost: drop backend_features field
by Markus Armbruster 12 Sep '25

12 Sep '25

Cc: libvirt Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> writes: > This field is mostly unused and sometimes confusing (we even have > a TODO-like comment to drop it). Let's finally do. > > The field is used to held VHOST_USER_F_PROTOCOL_FEATURES for vhost-user > and/or VHOST_NET_F_VIRTIO_NET_HDR for vhost-net (which may be > vhoust-user-net). But we can simply recalculte these two flags inplace > from hdev->features, and from net-client for > VHOST_NET_F_VIRTIO_NET_HDR. > > Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> [...] > diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h > index 66be6afc88..9f9dd2d46d 100644 > --- a/include/hw/virtio/vhost.h > +++ b/include/hw/virtio/vhost.h > @@ -100,16 +100,9 @@ struct vhost_dev { > * > * @features: available features provided by the backend > * @acked_features: final negotiated features with front-end driver > - * > - * @backend_features: this is used in a couple of places to either > - * store VHOST_USER_F_PROTOCOL_FEATURES to apply to > - * VHOST_USER_SET_FEATURES or VHOST_NET_F_VIRTIO_NET_HDR. Its > - * future use should be discouraged and the variable retired as > - * its easy to confuse with the VirtIO backend_features. I guess this is the TODO-like comment mentioned in the commit message. > */ > uint64_t features; > uint64_t acked_features; > - uint64_t backend_features; > > /** > * @protocol_features: is the vhost-user only feature set by > diff --git a/qapi/virtio.json b/qapi/virtio.json > index 9d652fe4a8..0aae77340d 100644 > --- a/qapi/virtio.json > +++ b/qapi/virtio.json > @@ -85,8 +85,6 @@ > # > # @acked-features: vhost_dev acked_features > # > -# @backend-features: vhost_dev backend_features > -# > # @protocol-features: vhost_dev protocol_features > # > # @max-queues: vhost_dev max_queues > @@ -106,7 +104,6 @@ > 'vq-index': 'int', > 'features': 'VirtioDeviceFeatures', > 'acked-features': 'VirtioDeviceFeatures', > - 'backend-features': 'VirtioDeviceFeatures', > 'protocol-features': 'VhostDeviceProtocols', > 'max-queues': 'uint64', > 'backend-cap': 'uint64', Incompatible change. We can do this because it's only visible in the return value of x-query-virtio-status, which is unstable. Recommend to note this in the commit message. Acked-by: Markus Armbruster <armbru(a)redhat.com>

1 0

[libvirt PATCH 0/2] bump minimum glib version to 2.68
by Ján Tomko 12 Sep '25

12 Sep '25

Ján Tomko (2): build: bump minimum glib version to 2.68 util: remove glibcompat.c meson.build | 2 +- src/conf/virdomainjob.c | 6 +- src/esx/esx_vi_types.c | 9 +- src/internal.h | 24 ---- src/libvirt_private.syms | 4 - src/qemu/qemu_capabilities.c | 8 +- src/util/glibcompat.c | 213 ----------------------------------- src/util/glibcompat.h | 29 ----- src/util/meson.build | 1 - 9 files changed, 13 insertions(+), 283 deletions(-) delete mode 100644 src/util/glibcompat.c -- 2.50.1

2 3

[PATCH 0/5] ch: Emit more events
by Michal Privoznik 12 Sep '25

12 Sep '25

*** BLURB HERE *** Michal Prívozník (5): ch: Emit event on device attach ch: Emit event on device attach ch: Propagate lifecycle events ch: Implement virConnectDomainEventRegister() ch: Implement virConnectDomainEventDeregister() src/ch/ch_driver.c | 41 +++++++++++++++++++++++++++++++++ src/ch/ch_events.c | 55 +++++++++++++++++++++++++++++++++++++++++++++ src/ch/ch_hotplug.c | 33 ++++++++++++++++++++++----- 3 files changed, 123 insertions(+), 6 deletions(-) -- 2.49.1

2 6

vDPA devices and random MAC address assignment
by Beñat Gartzia Arruabarrena 12 Sep '25

12 Sep '25

Hello, I am trying to find a solution to an issue related to vhost-vdpa devices and random mac addresses being assigned to them, if not set by the user. vDPA devices are assigned a MAC address the time they are created. That happens before creating the VM with qemu or libvirt. If the mac address of the vdpa device in the qemu command line does not match the mac address that was assigned to the vdpa device at creation time, the network traffic will not work. If the user does not explicitly configure a mac address for the vdpa device in the domain xml, libvirt will generate a random one and use it instead in the qemu command line. This leads to an interface that does not work. If I understood correctly, qemu is not able to update the mac address of the vdpa device based on the command line configuration, so setting the mac address generated by libvirt is not an option. Currently, a patch that introduces a set of checks comparing cmdline and device mac addresses is under review: https://lore.kernel.org/qemu-devel/20250417102522.4125379-1-lulu@redhat.com/ The implementation also adds the logic to configure the vdpa device mac address in the virtio net device if a mac address was not provided in the command line. I was trying to write a patch such that it would allow vdpa devices to have an empty mac address in the domain xml as an exception. The draft allowed such case in virDomainNetDefParseXML and virDomainNetDefFormat and avoided writing an empty mac address in the qemu command line by modifying the logic in qemuBuildNicDevProps. However, there are plenty of other functions and places that would expect the mac address to be there. Guarding against the empty mac addr case in all those places, is not desirable, I think. I'm not sure if libvirt could read the mac address of the device being assigned to the VM instead of generating a random mac address in the case of vdpa devices. It could probably require some code from qemu being duplicated. Could that be an acceptable alternative? I am also looking for any other recommendation on how I could look into this issue. Thanks a lot. Regards, Beñat

2 1

[PATCH v3 0/2] Introduce virDomainBlockRebaseParams API
by Nikolai Barybin 11 Sep '25

11 Sep '25

Changes since last revision: - Renamed API function name Nikolai Barybin (2): api: remote: introduce virDomainBlockRebaseParams API qemu: implement driver support for domainBlockRebaseParams API include/libvirt/libvirt-domain.h | 43 +++++++++++++++++++++ src/driver-hypervisor.h | 8 ++++ src/libvirt-domain.c | 65 ++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 5 +++ src/qemu/qemu_driver.c | 48 +++++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 ++++++++- src/remote_protocol-structs | 10 +++++ 8 files changed, 196 insertions(+), 1 deletion(-) -- 2.43.5

2 4

[PATCH 0/2] ch: Two simple fixes
by Michal Privoznik 11 Sep '25

11 Sep '25

While working on emitting more events from the CH driver and playing with cloud-hypervisor itself, I've noticed one memleak and one forgotten call to unlock. Michal Prívozník (2): ch: Avoid memory leak in virCHProcessEvents() ch: Unlock domain in virCHEventStopProcess() on all exit paths src/ch/ch_events.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.49.1

2 3

[PATCH 0/6] qemu: refactor disk migration safety check and add corner case exemption for Kubevirt's usage
by Peter Krempa 10 Sep '25

10 Sep '25

Patches 1-3 are refactors that simplify the code and prepare it. Patch 4 fixed bug where 'data_file' is not checked Patches 5 and 6 add a workaround for Kubevirt's corner case migration approach. Peter Krempa (6): qemuMigrationSrcIsSafe: Drop 'DEBUG' message about qemu supporting cache dropping qemuMigrationSrcIsSafe: Extract code for checking safe migrability of one disk qemuMigrationSrcIsSafeDisk: Extract safe migration checks for one storage source qemuMigrationSrcIsSafeDisk: Check also data file propertiues for migrability qemuBlockGetNamedNodeData: Extract 'data_file_raw' flag qemuMigrationSrcIsSafeDisk: Allow non-shared qcow2's with raw data file src/qemu/qemu_migration.c | 188 ++++++++++++------ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 3 + tests/qemublocktest.c | 2 + tests/qemublocktestdata/bitmap/synthetic.json | 1 + tests/qemublocktestdata/bitmap/synthetic.out | 1 + 6 files changed, 133 insertions(+), 65 deletions(-) -- 2.51.0

2 8

[PATCH v2 00/10] qemu: Fixes to firmware selection
by Andrea Bolognani 10 Sep '25

10 Sep '25

Changes from [v1]: * pick up Jim's test suite improvements; * squash in fixes for issues found during review; * add a few commits intented to spark further discussion around what the firmware descriptors should look like in the edk2 package. [v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/RKQ3… Andrea Bolognani (9): tests: Tweak descriptor for combined firmware tests: Minimize SEV tests tests: Add tests for SEV firmware selection qemu: Fix matching for stateless/combined firmware qemu: Fix matching for read/write firmware news: Update for firmware selection fixes DONOTMERGE update firmware data DONOTMERGE remove SEV features from non-SEV descriptors DONOTMERGE don't explicitly request stateless firmware for SEV Jim Fehlig (1): tests: Improve AMD SEV-related tests NEWS.rst | 5 ++ src/qemu/qemu_firmware.c | 47 ++++++++++++++----- .../firmware/60-edk2-ovmf-x64-amdsev.json | 1 - .../50-edk2-ovmf-4m-qcow2-x64-nosb.json | 2 - .../51-edk2-ovmf-2m-raw-x64-nosb.json | 2 - .../firmware/60-edk2-ovmf-x64-amdsev.json | 3 +- .../firmware/60-edk2-ovmf-x64-amdsevsnp.json} | 14 +++--- .../usr/share/qemu/firmware/90-combined.json | 5 +- tests/qemufirmwaretest.c | 4 +- ...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 ++++++++++++++ ...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 - ...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++- .../firmware-auto-efi-rw.x86_64-latest.args | 36 ++++++++++++++ .../firmware-auto-efi-rw.x86_64-latest.err | 1 - .../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++- ...auto-efi-sev-snp.x86_64-latest+amdsev.args | 35 ++++++++++++++ ...auto-efi-sev-snp.x86_64-latest+amdsev.xml} | 9 +++- .../firmware-auto-efi-sev-snp.xml | 20 ++++++++ ...are-auto-efi-sev.x86_64-latest+amdsev.args | 36 ++++++++++++++ ...are-auto-efi-sev.x86_64-latest+amdsev.xml} | 9 +++- .../qemuxmlconfdata/firmware-auto-efi-sev.xml | 20 ++++++++ ...urity-sev-direct.x86_64-latest+amdsev.args | 7 ++- ...curity-sev-direct.x86_64-latest+amdsev.xml | 19 +++----- ...nch-security-sev-direct.x86_64-latest.args | 7 ++- ...unch-security-sev-direct.x86_64-latest.xml | 19 +++----- .../launch-security-sev-direct.xml | 19 +------- ...ng-platform-info.x86_64-latest+amdsev.args | 9 ++-- ...ing-platform-info.x86_64-latest+amdsev.xml | 29 ++++++------ ...nch-security-sev-missing-platform-info.xml | 25 +++------- ...security-sev-snp.x86_64-latest+amdsev.args | 11 +---- ...-security-sev-snp.x86_64-latest+amdsev.xml | 29 +----------- ...launch-security-sev-snp.x86_64-latest.args | 11 +---- .../launch-security-sev-snp.x86_64-latest.xml | 29 +----------- .../launch-security-sev-snp.xml | 45 +----------------- ...nch-security-sev.x86_64-latest+amdsev.args | 9 ++-- ...unch-security-sev.x86_64-latest+amdsev.xml | 29 ++++++------ tests/qemuxmlconfdata/launch-security-sev.xml | 25 +++------- tests/qemuxmlconftest.c | 11 ++++- 38 files changed, 352 insertions(+), 279 deletions(-) copy tests/qemufirmwaredata/{out/usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json => usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsevsnp.json} (57%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml} (78%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.x86_64-latest+amdsev.args copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev.x86_64-latest+amdsev.xml} (77%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev.xml -- 2.51.0

2 24