February 2025 - Devel - libvirt List Archives

[PATCH 0/4] Add support for MSDM ACPI table type
by Daniel P. Berrangé 20 Feb '25

20 Feb '25

This was requested by KubeVirt in https://gitlab.com/libvirt/libvirt/-/issues/748 I've not functionally tested this, since I lack any suitable guest windows environment this is looking for MSDM tables, nor does my machine have MSDM ACPI tables to pass to a guest. I'm blindly assuming that the QEMU CLI code is identical except for s/SLIC/MSDM/. Also I'm pretty unhappy about the situation with the Xen driver support. This is pre-existing, and IMHO should never have been added as it exists today, as it allows arbitrary passthrough of *any* set of ACPI tables, as opposed to a single type of the specific type listed in the XML. This should have been handled with a different XML syntax, but with stuck with this undesirable approach now, so I've kept it as is. Daniel P. Berrangé (4): conf: introduce support for multiple ACPI tables src: validate permitted ACPI table types in libxl/qemu drivers conf: support MSDM ACPI table type qemu: support MSDM ACPI table type docs/formatdomain.rst | 4 +- src/conf/domain_conf.c | 88 ++++++++++++++----- src/conf/domain_conf.h | 22 ++++- src/conf/schemas/domaincommon.rng | 5 +- src/libvirt_private.syms | 2 + src/libxl/libxl_conf.c | 8 +- src/libxl/libxl_domain.c | 21 +++++ src/libxl/xen_xl.c | 22 ++++- src/qemu/qemu_command.c | 14 ++- src/qemu/qemu_validate.c | 16 ++++ src/security/security_dac.c | 18 ++-- src/security/security_selinux.c | 16 ++-- src/security/virt-aa-helper.c | 5 +- .../acpi-table-many.x86_64-latest.args | 34 +++++++ .../acpi-table-many.x86_64-latest.xml | 39 ++++++++ tests/qemuxmlconfdata/acpi-table-many.xml | 31 +++++++ tests/qemuxmlconftest.c | 1 + 17 files changed, 296 insertions(+), 50 deletions(-) create mode 100644 tests/qemuxmlconfdata/acpi-table-many.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-table-many.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-table-many.xml -- 2.47.1

3 12

Re: [PATCH 1/1] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Michal Prívozník 20 Feb '25

20 Feb '25

On 2/14/25 02:06, Akio Kakuno (Fujitsu) via Devel wrote: > Hi, all! > > I'm adding three test for CCA compatibility: > domaincapstest, qemucapabilitiestest, and qemuxmlconftest. > This is because SEV-SNP added these three tests. > > I have three questions regarding these tests: > 1. How to add tests to qemuxmlconftest > 2. How to create launch-security-cca.xml > 3. About the file output with VIR_TEST_REGENERATE_OUTPUT=1 > > 1. How to add tests to qemuxmlconftest > Following the example of launch-security-sev-snp tests, I've done the following. > Is this correct? > > (1) Placed the following three files in tests/qemuxmlconfdata: > launch-security-cca.xml > launch-security-cca.aarch64-latest.xml > launch-security-cca.aarch64-latest.args > The placement is correct, yes. BUT ... > (2) Added the test processing to qemuxmlconftest.c's mymain() function: > DO_TEST_CAPS_ARCH_LATEST_FULL("launch-security-cca", > "aarch64", > ARG_QEMU_CAPS, > QEMU_CAPS_CCA_GUEST, > QEMU_CAPS_LAST); ... this can be simplified to: DO_TEST_CAPS_ARCH_LATEST("launch-security-cca", "aarch64"); > > 2. How to create launch-security-cca.xml > Do I need to handmade this from scratch or is there an automated method? Basically it's hand written. What I usually do is I copy-paste the domain XML I used when developing and testing a feature. And then cut off all unnecessary elements. > > 3. About the file output with VIR_TEST_REGENERATE_OUTPUT=1 > I created launch-security-cca.aarch64-latest.* using the method described in > doc/advanced-tests.rst. > And, I created the test data for qemucapabilitiestest and domaincapstest using > the method described in tests/qemucapabilitiesdata/README.rst. > VIR_TEST_REGENERATE_OUTPUT=1 ./qemuxmlconftest > VIR_TEST_REGENERATE_OUTPUT=1 ./domaincapstest > VIR_TEST_REGENERATE_OUTPUT=1 ./qemucapabilitiestest > > Can I use the generated file for testing as is? > Because doc/advanced-tests.rst says: > "VERY CAREFULLY to ensure they are correct" > > I assume that automatically generated expected values are checked for accuracy. Not really. It takes a machine brain to decide whether those files follow some syntax (e.g. whether JSON is valid), but it takes human brain to decide whether full combination of cmd line arguments actually makes sense. I'd say - if you're able to start generated cmd line (modulo some FD passing stuff - see my point above about cutting off unnecessary elements), then you're probably fine. > If correct, they are adopted; otherwise, investigation and remediation are undertaken. > However, due to the lack of explicit documentation, we require confirmation. > > Also, it appears to be generating expected values based on the execution environment. > Do we need to worry about variations in execution environments? No. Our tests should generate stable enough (and reproducible!) environment. > For example, executing qemuxmlconftest detects the following comparison errors, > such as with aarch64-virt-minimal.aarch64-latest, etc. > Expect [sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ > -m] > Actual [m] Yeah, printing diffs is not very userfriendly. You can get better results with VIR_TEST_DEBUG=2. > > Best Regards. > Michal

2 1

[PATCH v7 00/18] *** [PATCH v7 00/18] qemu: block: Support block disk along with throttle filters ***
by Harikumar Rajkumar 19 Feb '25

19 Feb '25

*** Support block disk along with throttle filters *** Harikumar Rajkumar (18): schema: Add new domain elements to support multiple throttle groups schema: Add new domain elements to support multiple throttle filters config: Introduce ThrottleGroup and corresponding XML parsing config: Introduce ThrottleFilter and corresponding XML parsing qemu: monitor: Add support for ThrottleGroup operations tests: Test qemuMonitorJSONGetThrottleGroup and qemuMonitorJSONUpdateThrottleGroup remote: New APIs for ThrottleGroup lifecycle management qemu: Refactor qemuDomainSetBlockIoTune to extract common methods qemu: Implement qemu driver for throttle API qemu: helper: throttle filter nodename and preparation processing qemu: block: Support block disk along with throttle filters config: validate: Verify iotune, throttle group and filter qemuxmlconftest: Add 'throttlefilter' tests qemustatusxml2xmldata: Add 'throttlefilter' tests test_driver: Test throttle group lifecycle APIs virsh: Refactor iotune options for re-use virsh: Add support for throttle group operations virsh: Add option throttle-groups to attach_disk docs/formatdomain.rst | 47 ++ docs/manpages/virsh.rst | 137 +++- include/libvirt/libvirt-domain.h | 14 + src/conf/domain_conf.c | 407 ++++++++++ src/conf/domain_conf.h | 47 ++ src/conf/domain_validate.c | 118 ++- src/conf/schemas/domaincommon.rng | 293 ++++--- src/conf/virconftypes.h | 4 + src/driver-hypervisor.h | 14 + src/libvirt-domain.c | 122 +++ src/libvirt_private.syms | 8 + src/libvirt_public.syms | 6 + src/qemu/qemu_block.c | 136 ++++ src/qemu/qemu_block.h | 49 ++ src/qemu/qemu_command.c | 180 +++++ src/qemu/qemu_command.h | 6 + src/qemu/qemu_domain.c | 77 +- src/qemu/qemu_driver.c | 486 +++++++++--- src/qemu/qemu_hotplug.c | 29 + src/qemu/qemu_monitor.c | 21 + src/qemu/qemu_monitor.h | 9 + src/qemu/qemu_monitor_json.c | 129 +++ src/qemu/qemu_monitor_json.h | 14 + src/remote/remote_daemon_dispatch.c | 105 +++ src/remote/remote_driver.c | 3 + src/remote/remote_protocol.x | 50 +- src/remote_protocol-structs | 28 + src/test/test_driver.c | 367 ++++++--- tests/qemumonitorjsontest.c | 86 ++ .../throttlefilter-in.xml | 392 ++++++++++ .../throttlefilter-out.xml | 393 ++++++++++ tests/qemuxmlactivetest.c | 1 + .../throttlefilter-invalid.x86_64-latest.err | 1 + .../throttlefilter-invalid.xml | 89 +++ .../throttlefilter.x86_64-latest.args | 55 ++ .../throttlefilter.x86_64-latest.xml | 105 +++ tests/qemuxmlconfdata/throttlefilter.xml | 95 +++ tests/qemuxmlconftest.c | 2 + tools/virsh-completer-domain.c | 82 ++ tools/virsh-completer-domain.h | 16 + tools/virsh-domain.c | 736 ++++++++++++++---- 41 files changed, 4429 insertions(+), 530 deletions(-) create mode 100644 tests/qemustatusxml2xmldata/throttlefilter-in.xml create mode 100644 tests/qemustatusxml2xmldata/throttlefilter-out.xml create mode 100644 tests/qemuxmlconfdata/throttlefilter-invalid.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/throttlefilter-invalid.xml create mode 100644 tests/qemuxmlconfdata/throttlefilter.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/throttlefilter.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/throttlefilter.xml -- 2.39.5 (Apple Git-154)

2 24

libvirt hook to change domain xml
by Victor Toso 19 Feb '25

19 Feb '25

Hi, I'm particularly interested in the PoC of KubeVirt to allow custom changes in libvirt domain xml in a more straightforward manner than they have Today [0]. When I was looking into the libvirt hooks, I was a bit excited when I read: > you can also place several hook scripts in the directory > /etc/libvirt/hooks/qemu.d/. They are executed in alphabetical > order after main script. In this case each script also acts as > filter and can modify the domain XML and print it out on its > standard output. This script output is passed to standard > input next script in order. Empty output from any script is > also identical to copying the input XML without changing it. > In case any script returns failure common process will be > aborted, but all scripts from the directory will are executed. But that's not the case for every situation. When the domain is being defined the scripts are run but the output is ignored [1] Is there a reason for that? In KubeVirt we basically have to re-implement [2] what the logic around scripts under qemu.d already does. If we could use libvirt only it would make testing easier for users and less code on KubeVirt. [0] https://kubevirt.io/user-guide/user_workloads/hook-sidecar/ [1] https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_process.c#L4… [2] https://github.com/kubevirt/kubevirt/blob/main/pkg/hooks/manager.go#L200 Cheers, Victor

3 6

[PATCH 00/12] [PATCH v2 00/12] qemu: support passt as a backend for vhost-user network interfaces
by Laine Stump 18 Feb '25

18 Feb '25

==== Changes from V1: * fixed missing change to error log message pointed out by abologna * added a validation check to assure that shared memory is enabled if there is a type='vhostuser' interface in the domain definition * included a patch documenting differences between type='user' SLIRP and passt behaviors (because I had to do it anyway, and the reorganization made documenting type='vhostuser' passt slightly easier. * added documentation for type='vhostuser' backend type='passt' ===== passt (https://passt.top) provides a method of connecting QEMU virtual machines to the external network without requiring special privileges or capabilities of any participating processes - even libvirt itself can run unprivileged and create an instance of passt (which *always* runs unprivileged) that is then connected to the qemu process (and thus the virtual machine) with a unix socket. Originally passt used its own protocol for this socket, sending both control messages and data packets over the socket. This works, and is already much more efficient than the previously only-unprivileged-networking-solution slirp. But recently passt added support for using the vhost-user protocol for communication between the passt process (which is connected to the external network) and the QEMU process (and thus the VM). vhost-user also uses a unix socket, but only for control plane messages - all data packets are "sent" between the VM and passt process via a shared memory region. This is unsurprisingly much more efficient. From the point of view of QEMU, the passt process looks identical to any normal vhost-user backend, so we can run QEMU with exactly the same interface commandline options as normal vhost-user. Also, the passt process supports all of the same options as it does when used in its "traditional" mode, so really in the end all we need to do is twist libvirt around so that when <backend type='passt'/> is specified for an <interface type='vhostuser'>, it will run passt just as before (except with the added "--vhost-user" option so that passt will know to use that), and then force feed the vhost-user code in libvirt with the same socket path used by passt. This series does that, while also switching up a few bits of code prior to adding in the new functionality. So far this has been tested both unprivileged and privileged on Fedora 40 (with latest passt packet) and selinux enabled (there are a couple of selinux policy tweaks that still need to be pushed to passt-selinux) as well as unprivileged on debian (I *think* with AppArmor enabled) and everything seems to work. (I haven't gotten to testing hotplug, but it *should* work, and I'll be testing it while (hopefully) someone is reviewing these patches.) To test, you will need the latest (20250121) passt package and the aforementioned upstream passt-selinux patch if you're using selinux. This Resolves: https://issues.redhat.com/browse/RHEL-69455 Laine Stump (12): conf: change virDomainHostdevInsert() to return void qemu: fix qemu validation to forbid guest-side IP address for type='vdpa' qemu: validate that model is virtio for vhostuser and vdpa interfaces in the same place qemu: automatically set model type='virtio' for interface type='vhostuser' qemu: do all vhostuser attribute validation in qemu driver conf/qemu: make <source> element *almost* optional for type=vhostuser qemu: use switch instead of if in qemuProcessPrepareDomainNetwork() qemu: make qemuPasstCreateSocketPath() public qemu: complete vhostuser + passt support qemu: fail validation if a domain def has vhostuser/passt but no shared mem docs: improve type='user' docs to higlight differences between SLIRP and passt docs: document using passt backend with <interface type='vhostuser'> docs/formatdomain.rst | 189 +++++++++++++----- src/conf/domain_conf.c | 107 +++++----- src/conf/domain_conf.h | 2 +- src/conf/domain_validate.c | 85 +++----- src/conf/schemas/domaincommon.rng | 32 ++- src/libxl/libxl_domain.c | 5 +- src/libxl/libxl_driver.c | 3 +- src/lxc/lxc_driver.c | 3 +- src/qemu/qemu_command.c | 7 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_extdevice.c | 6 +- src/qemu/qemu_hotplug.c | 21 +- src/qemu/qemu_passt.c | 5 +- src/qemu/qemu_passt.h | 3 + src/qemu/qemu_postparse.c | 3 +- src/qemu/qemu_process.c | 85 +++++--- src/qemu/qemu_validate.c | 65 ++++-- ...t-user-slirp-portforward.x86_64-latest.err | 2 +- ...vhostuser-passt-no-shmem.x86_64-latest.err | 1 + .../net-vhostuser-passt-no-shmem.xml | 70 +++++++ .../net-vhostuser-passt.x86_64-latest.args | 42 ++++ .../net-vhostuser-passt.x86_64-latest.xml | 75 +++++++ tests/qemuxmlconfdata/net-vhostuser-passt.xml | 73 +++++++ tests/qemuxmlconftest.c | 2 + 24 files changed, 657 insertions(+), 232 deletions(-) create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt-no-shmem.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt-no-shmem.xml create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt.xml -- 2.47.1

4 24

[PATCH] build-aux: squelch trailing blank warnings from binary files
by Daniel P. Berrangé 18 Feb '25

18 Feb '25

These files pollute the stderr output when the sc_trailing_blank syntax check fails. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- build-aux/syntax-check.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build-aux/syntax-check.mk b/build-aux/syntax-check.mk index e6afb879be..bd3dd6cb54 100644 --- a/build-aux/syntax-check.mk +++ b/build-aux/syntax-check.mk @@ -1438,7 +1438,7 @@ exclude_file_name_regexp--sc_require_config_h_first = \ ^(examples/|tools/virsh-edit\.c$$|tests/virmockstathelpers\.c$$|scripts/rpcgen/tests/test_demo\.c$$) exclude_file_name_regexp--sc_trailing_blank = \ - /sysinfodata/.*\.data|/virhostcpudata/.*\.cpuinfo|tests/virshtestdata/.*$$ + /sysinfodata/.*\.data|/virhostcpudata/.*\.cpuinfo|tests/virshtestdata/.*|docs/fonts|scripts/rpcgen/tests/.*\.bin|tests/viracpidata/.*|tests/virpcitestdata/*|tests/virstoragetestdata/images/.*\.qcow2$$ exclude_file_name_regexp--sc_unmarked_diagnostics = \ ^(scripts/apibuild.py|tests/virt-aa-helper-test|docs/js/.*\.js)$$ -- 2.47.1

2 1

[PATCH] qemu: Avoid crash in qemuDomainCheckCPU with unknown host CPU
by Jiri Denemark 18 Feb '25

18 Feb '25

When we don't have any information about host CPU (for example when running on an aarch64 host), the virQEMUCapsGetHostModel would return NULL. Fixes: https://gitlab.com/libvirt/libvirt/-/issues/747 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_domain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index cf05dca55a..df1ed0223d 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11430,6 +11430,7 @@ qemuDomainCheckCPU(virArch arch, /* Force compat check if the CPU model is not found in qemuCaps or * we don't have host CPU data from QEMU */ if (!cpu->model || + !hypervisorCPU || hypervisorCPU->fallback != VIR_CPU_FALLBACK_FORBID || virQEMUCapsGetCPUBlockers(qemuCaps, virtType, cpu->model, &blockers) < 0) -- 2.48.1

3 2

Plans for 11.1.0 release (freeze on Monday 24 Feb)
by Jiri Denemark 18 Feb '25

18 Feb '25

We are getting close to 11.1.0 release of libvirt. To aim for the release on Monday 03 Mar I suggest entering the freeze on Monday 24 Feb and tagging RC2 on Thursday 27 Feb. I hope this works for everyone. Jirka

1 0

[PATCH] util: fix compile warning in virsystemd.c during mingw builds
by Laine Stump 18 Feb '25

18 Feb '25

A function was changed from having no arguments to having a single argument, but the entire body of the function was #ifdefed out for windows builds, leaving that new argument unused. Surprisingly this didn't cause the build to fail, but I happened to notice it flit by during an rpm build. Fixes: 785cd56e5803fbbf60715fb6c7536360df5b4b9e Signed-off-by: Laine Stump <laine(a)redhat.com> --- I'm pushing this as trivial (technically it's not a build breaker, since the build still continues even with the warning :-P) src/util/virsystemd.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/util/virsystemd.c b/src/util/virsystemd.c index 57fe409c57..92d2890360 100644 --- a/src/util/virsystemd.c +++ b/src/util/virsystemd.c @@ -624,10 +624,15 @@ int virSystemdTerminateMachine(const char *name) return 0; } +#ifdef WIN32 +static void +virSystemdNotify(const char *msg G_GNUC_UNUSED) +{ +} +#else static void virSystemdNotify(const char *msg) { -#ifndef WIN32 const char *path; int fd; struct sockaddr_un un = { @@ -672,8 +677,8 @@ virSystemdNotify(const char *msg) VIR_WARN("Failed to notify systemd"); VIR_FORCE_CLOSE(fd); -#endif /* !WIN32 */ } +#endif /* !WIN32 */ void virSystemdNotifyReady(void) { -- 2.47.1

1 0

[PATCH] utils: Canonicalize paths before comparing them
by Andrea Bolognani 17 Feb '25

17 Feb '25

Resolves: https://issues.redhat.com/browse/RHEL-79165 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/util/virfile.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index 6ac0f4efb3..7cab3d0cd6 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -3823,10 +3823,13 @@ virFileIsSharedFSOverride(const char *path, if (!path || path[0] != '/' || !overrides) return false; - if (g_strv_contains((const char *const *) overrides, path)) - return true; + /* Overrides have been canonicalized ahead of time, so we need to + * do the same for the provided path or we'll never be able to + * find a match if symlinks are involved */ + dirpath = virFileCanonicalizePath(path); - dirpath = g_strdup(path); + if (g_strv_contains((const char *const *) overrides, dirpath)) + return true; /* Continue until we've scanned the entire path */ while (p != dirpath) { -- 2.48.1

2 2