- Devel - libvirt List Archives

[PATCH] commandtest: Comply with FreeBSD poll()
by Michal Privoznik 01 Dec '22

01 Dec '22

In one of recent commits I've introduced a new test case to commandtest. In the test case I'm using poll() to wait for data on a pipe (the write end is passed to commandhelper). However, on FreeBSD the POLLIN semantic is a bit different: POLLIN Data other than high priority data may be read without blocking. Well, the pipe is non-blocking, so even if there's no data to be read the flag is set (and subsequent read() returns 0). On the other hand, POLLHUP is set too, BUT, if the commandhelper manages to write everything into the pipe and die right after we'd get both POLLIN and POLLHUP after the very first time poll() returns. That's very unfortunate, but okay - we can just check whether read() returned zero and break from the reading loop. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/commandtest.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/commandtest.c b/tests/commandtest.c index 62275ba96d..688cf59160 100644 --- a/tests/commandtest.c +++ b/tests/commandtest.c @@ -1205,6 +1205,9 @@ test29(const void *unused G_GNUC_UNUSED) goto cleanup; } + if (rc == 0) + break; + outactual = g_renew(char, outactual, outactuallen + rc + 1); memcpy(outactual + outactuallen, buf, rc); outactuallen += rc; -- 2.37.4

2 1

Release of libvirt-8.10.0
by Jiri Denemark 01 Dec '22

01 Dec '22

The 8.10.0 release of both libvirt and libvirt-python is tagged and signed tarballs and source RPMs are available at https://libvirt.org/sources/ https://libvirt.org/sources/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * New features * Tool for validating SEV firmware boot measurement of QEMU VMs The ``virt-qemu-sev-validate`` program will compare a reported SEV/SEV-ES domain launch measurement, to a computed launch measurement. This determines whether the domain has been tampered with during launch. * Support for SGX EPC (enclave page cache) Users can add a ``<memory model='sgx-epc'>`` device to lauch a VM with ``Intel Software Guard Extensions``. * Support migration of vTPM state of QEMU vms on shared storage Pass ``--migration`` option if appropriate in order for ``swtpm`` to properly migrate on shared storage. * Improvements * Mark close callback (un-)register API as high priority High priority APIs use a separate thread pool thus can help in eliminating problems with stuck VMs. Marking the close callback API as high priority allows ``virsh`` to properly connect to the daemon in case the normal priority workers are stuck allowing other high priority API usage. * Updated x86 CPU features The following features for the x86 platform were added: ``v-vmsave-vmload``, ``vgif``, ``avx512-vp2intersect``, ``avx512-fp16``, ``serialize``, ``tsx-ldtrk``, ``arch-lbr``, ``xfd``, ``intel-pt-lip``, ``avic``, ``sgx``, ``sgxlc``, ``sgx-exinfo``, ``sgx1``, ``sgx2``, ``sgx-debug``, ``sgx-mode64``, ``sgx-provisionkey``, ``sgx-tokenkey``, ``sgx-kss``, ``bus-lock-detect``, ``pks``, ``amx``. * Add support for ``hv-avic`` Hyper-V enlightenment ``qemu-6.2`` introduced support for the ``hv-avic`` enlightenment which allows to use Hyper-V SynIC with hardware APICv/AVIC enabled. * qemu: Run memory preallocation with numa-pinned threads Run the thread allocating memory in the proper NUMA node to reduce overhead. * RPM packaging changes - add optional dependancy of ``libvirt-daemon`` on ``libvirt-client`` The ``libvirt-guests.`` tool requires the ``virsh`` client to work properly, but we don't want to require the installation of the daemon if the tool is not used. - relax required ``python3-libvirt`` version for ``libvirt-client-qemu`` The ``virt-qemu-qmp-proxy`` tool requires python but doesn't strictly need the newest version. Remove the strict versioning requirement in order to prevent cyclic dependency when building. * Bug fixes * Skip initialization of ``cache`` capabilities if host doesn't support them Hypervisor drivers would fail to initialize on ``aarch64`` hosts with following error :: virStateInitialize:657 : Initialisation of cloud-hypervisor state driver failed: no error which prevented the startup of the daemon. * Allow incoming connections to guests on routed networks w/firewalld A change in handling of implicit rules in ``firewalld 1.0.0`` broke incomming connections to VMs when using ``routed`` network. This is fixed by adding a new ``libvirt-routed`` zone configured to once again allow incoming sessions to guests on routed networks. * Fix infinite loop in nodedev driver Certain udev entries might be of a size that makes libudev emit EINVAL which caused a busy loop burning CPU. Fix it by ignoring the return code. Enjoy. Jirka

1 0

[PATCH 0/9] Couple of virCommand related improvements
by Michal Privoznik 30 Nov '22

30 Nov '22

Found these on a abandoned branch, but they are still worth merging. Polished them a bit though. Michal Prívozník (9): vircommand: Document virCommandSetSendBuffer() behaviour wrt daemonize virCommandDoAsyncIO: Drop misleading statement about main event loop commandtest: Use unsigned char in test27() virCommandSetSendBuffer: Take double pointer of @buffer commandtest: Test virCommandSetSendBuffer() with virCommandDoAsyncIO() commandtest: Use virTestCompareToFile() in checkoutput() virbuftest: Cleanup code around virTestDifference() tests: Don't wrap virTestDifference() arguments in NULLSTR() tests: Use virTestCompareToString() more src/qemu/qemu_tpm.c | 2 +- src/util/vircommand.c | 11 ++- src/util/vircommand.h | 2 +- tests/commanddata/test29.log | 20 ++++ tests/commandtest.c | 152 +++++++++++++++++++++++-------- tests/esxutilstest.c | 10 +- tests/nwfilterebiptablestest.c | 21 ++--- tests/openvzutilstest.c | 6 +- tests/sockettest.c | 3 +- tests/utiltest.c | 3 +- tests/vboxsnapshotxmltest.c | 3 +- tests/virbuftest.c | 25 ++--- tests/virfirewalltest.c | 30 ++---- tests/virjsontest.c | 6 +- tests/virkmodtest.c | 3 +- tests/virnetdevbandwidthtest.c | 5 +- tests/virnetdevopenvswitchtest.c | 10 +- tests/virnetsockettest.c | 3 +- tests/virshtest.c | 3 +- 19 files changed, 182 insertions(+), 136 deletions(-) create mode 100644 tests/commanddata/test29.log -- 2.37.4

2 10

[libvirt PATCH] apparmor: Allow running /usr/libexec/qemu-kvm
by Andrea Bolognani 30 Nov '22

30 Nov '22

Distros that use AppArmor, such as Debian and Ubuntu, install QEMU under /usr/bin/qemu-system-*, and our AppArmor profile is written with that assumption in mind. If you try to run the RHEL or CentOS version of libvirt and QEMU inside a privileged container on such distros, however, that will result in an error, because the path /usr/libexec/qemu-kvm is used instead. In particular, this prevents upstream KubeVirt releases (which are based on CentOS) from running on Debian/Ubuntu nodes. See https://github.com/kubevirt/kubevirt/pull/8692 and the issues referenced therein for additional details. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/security/apparmor/usr.sbin.libvirtd.in | 4 ++++ src/security/apparmor/usr.sbin.virtqemud.in | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/src/security/apparmor/usr.sbin.libvirtd.in b/src/security/apparmor/usr.sbin.libvirtd.in index 886f1ad518..2994de5ec9 100644 --- a/src/security/apparmor/usr.sbin.libvirtd.in +++ b/src/security/apparmor/usr.sbin.libvirtd.in @@ -99,6 +99,10 @@ profile libvirtd @sbindir@/libvirtd flags=(attach_disconnected) { # read and run an ebtables script. /var/lib/libvirt/virtd* ixr, + # Needed when running the RHEL/CentOS version of libvirt and QEMU + # inside a privileged container on a Debian/Ubuntu host + /usr/libexec/qemu-kvm PUx, + # force the use of virt-aa-helper audit deny /{usr/,}sbin/apparmor_parser rwxl, audit deny /etc/apparmor.d/libvirt/** wxl, diff --git a/src/security/apparmor/usr.sbin.virtqemud.in b/src/security/apparmor/usr.sbin.virtqemud.in index 3de03d49fc..b3f33b9471 100644 --- a/src/security/apparmor/usr.sbin.virtqemud.in +++ b/src/security/apparmor/usr.sbin.virtqemud.in @@ -94,6 +94,10 @@ profile virtqemud @sbindir@/virtqemud flags=(attach_disconnected) { # read and run an ebtables script. /var/lib/libvirt/virtd* ixr, + # Needed when running the RHEL/CentOS version of libvirt and QEMU + # inside a privileged container on a Debian/Ubuntu host + /usr/libexec/qemu-kvm PUx, + # force the use of virt-aa-helper audit deny /{usr/,}sbin/apparmor_parser rwxl, audit deny /etc/apparmor.d/libvirt/** wxl, -- 2.38.1

4 12

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

30 Nov '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 existence of share storage influences the management of the directory structure holding the TPM state, which for example is only removed when a domain is undefined and not when a VM is removed on the migration source host. Further, when shared storage is used then 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 by NFS. For shared storage support to work properly both sides of the migration need to be clients of the shared storage setup, meaning that they both have to have /var/lib/libvirt/swtpm mounted as shared storage, because other- wise the virFileIsSharedFS() may not detect shared storage and in the worst case may cause the TPM emulator (swtpm) to malfunction if for example the source side removed the TPM state directory structure. Shared storage migration requires (upcoming) swtpm v0.8. Stefan v4: - Fixed long-standing bug regarding offline migration that now blocks if no shared storage is set up - Addressed Michal's concerns v3: - Relying entirely on virFileIsSharedFS() on migration source and destination sides to detect whether shared storage is set up between hosts; no more hint about shared storage from user via flag - Added support for virDomainTPMPrivate structure to store and persist TPM-related private data Stefan Berger (7): util: Add parsing support for swtpm's cmdarg-migration capability qemu: tpm: Allow offline migration with TPM_EMULATOR only with shared storage qemu: tpm: Conditionally create storage on incoming migration qemu: tpm: Add support for storing private TPM-related data qemu: tpm: Pass --migration option to swtpm if supported and needed qemu: tpm: Avoid security labels on incoming migration with shared storage qemu: tpm: Never remove state on outgoing migration and shared storage src/conf/domain_conf.c | 63 ++++++++++++++++++-- src/conf/domain_conf.h | 9 +++ src/qemu/qemu_domain.c | 85 ++++++++++++++++++++++++-- src/qemu/qemu_domain.h | 17 +++++- src/qemu/qemu_driver.c | 20 +++---- src/qemu/qemu_extdevice.c | 10 ++-- src/qemu/qemu_extdevice.h | 6 +- src/qemu/qemu_migration.c | 28 +++++++-- src/qemu/qemu_process.c | 9 ++- src/qemu/qemu_snapshot.c | 4 +- src/qemu/qemu_tpm.c | 122 ++++++++++++++++++++++++++++++++++---- src/qemu/qemu_tpm.h | 14 ++++- src/util/virtpm.c | 1 + src/util/virtpm.h | 1 + 14 files changed, 339 insertions(+), 50 deletions(-) -- 2.37.3

2 18

[libvirt PATCH 0/3] qemu: A few qemuMigrationCookieParse cleanups
by Jiri Denemark 30 Nov '22

30 Nov '22

Jiri Denemark (3): qemu: Reorder qemuMigrationCookieParse arguments qemu: Replace priv with qemuCaps in qemuMigrationCookieParse qemu: Reindent qemuMigrationCookieParse prototype arguments src/qemu/qemu_migration.c | 35 ++++++++++++++++-------------- src/qemu/qemu_migration_cookie.c | 12 ++++------ src/qemu/qemu_migration_cookie.h | 14 ++++++------ tests/qemumigrationcookiexmltest.c | 6 ++--- 4 files changed, 33 insertions(+), 34 deletions(-) -- 2.38.1

2 4

[PATCH] node_device_conf: Avoid memleak in virNodeDeviceGetPCIVPDDynamicCap()
by Michal Privoznik 30 Nov '22

30 Nov '22

The virNodeDeviceGetPCIVPDDynamicCap() function is called from virNodeDeviceGetPCIDynamicCaps() and therefore has to be a wee bit more clever about adding VPD capability. Namely, it has to remove the old one before adding a new one. This is how other functions called from virNodeDeviceGetPCIDynamicCaps() behave as well. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143235 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/node_device_conf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index 83e66b85e3..af331baaf3 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -3068,6 +3068,9 @@ virNodeDeviceGetPCIVPDDynamicCap(virNodeDevCapPCIDev *devCapPCIDev) virPCIDeviceAddress devAddr = { 0 }; g_autoptr(virPCIVPDResource) res = NULL; + g_clear_pointer(&devCapPCIDev->vpd, virPCIVPDResourceFree); + devCapPCIDev->flags &= ~VIR_NODE_DEV_CAP_FLAG_PCI_VPD; + devAddr.domain = devCapPCIDev->domain; devAddr.bus = devCapPCIDev->bus; devAddr.slot = devCapPCIDev->slot; @@ -3081,8 +3084,6 @@ virNodeDeviceGetPCIVPDDynamicCap(virNodeDevCapPCIDev *devCapPCIDev) if ((res = virPCIDeviceGetVPD(pciDev))) { devCapPCIDev->flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VPD; devCapPCIDev->vpd = g_steal_pointer(&res); - } else { - virPCIVPDResourceFree(g_steal_pointer(&devCapPCIDev->vpd)); } } return 0; -- 2.37.4

2 1

[libvirt PATCH] qemu: Pass vm to qemuMigrationCookieParse if it exists
by Jiri Denemark 30 Nov '22

30 Nov '22

The vm object is used inside qemuMigrationCookieParse based on the flags passed to qemuMigrationCookieParse and the content of the cookie. The callers should not just blindly guess and pass NULL if they (incorrectly) think the vm object is not needed. We should always pass the vm object unless it does not exist yet. This fixes a bug when statistics of a completed migration reported "Unknown" operation instead of "Incoming migration" on the destination host. https://bugzilla.redhat.com/show_bug.cgi?id=2137298 Fixes: v8.7.0-79-g0150f7a8c1 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index bef06f4caf..6d3810c79c 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -4775,7 +4775,7 @@ qemuMigrationSrcRun(virQEMUDriver *driver, QEMU_MIGRATION_COOKIE_GRAPHICS | QEMU_MIGRATION_COOKIE_CAPS | QEMU_MIGRATION_COOKIE_BLOCK_DIRTY_BITMAPS, - NULL); + vm); if (!mig) goto error; @@ -6459,7 +6459,7 @@ qemuMigrationDstFinishOffline(virQEMUDriver *driver, g_autoptr(qemuMigrationCookie) mig = NULL; if (!(mig = qemuMigrationCookieParse(driver, vm->def, priv->origname, priv, - cookiein, cookieinlen, cookie_flags, NULL))) + cookiein, cookieinlen, cookie_flags, vm))) return NULL; if (qemuMigrationDstPersist(driver, vm, mig, false) < 0) @@ -6655,7 +6655,7 @@ qemuMigrationDstFinishActive(virQEMUDriver *driver, vm, flags, retcode); if (!(mig = qemuMigrationCookieParse(driver, vm->def, priv->origname, priv, - cookiein, cookieinlen, cookie_flags, NULL))) + cookiein, cookieinlen, cookie_flags, vm))) goto error; if (retcode != 0) { -- 2.38.1

2 1

[PATCH 0/2] logging: add log cleanup for obsolete domains
by Oleg Vasilev 30 Nov '22

30 Nov '22

Motivation comes from the case when libguestfs has repeatedly created transient VMs, which in turn created lots of logs without any mechanism to delete it afterwards. More motivation in [1]. Previous attempt in [2]. [1]: https://listman.redhat.com/archives/libvir-list/2022-February/msg00425.html [2]: https://listman.redhat.com/archives/libvir-list/2022-February/msg00865.html Oleg Vasilev (2): logging: refactor to store config inside log handler logging: add log cleanup for obsolete domains src/logging/log_daemon.c | 6 +- src/logging/log_daemon_config.c | 9 ++ src/logging/log_daemon_config.h | 3 + src/logging/log_handler.c | 137 +++++++++++++++++++++++++++---- src/logging/log_handler.h | 17 ++-- src/logging/test_virtlogd.aug.in | 2 + src/logging/virtlogd.aug | 2 + src/logging/virtlogd.conf | 7 ++ 8 files changed, 153 insertions(+), 30 deletions(-) -- 2.38.1

2 5

[PATCH] Fix couple of comment typos
by Martin Kletzander 30 Nov '22

30 Nov '22

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed as trivial. examples/c/admin/list_clients.c | 2 +- examples/c/admin/logging.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/c/admin/list_clients.c b/examples/c/admin/list_clients.c index 70907b4fba2f..169c9a7ec814 100644 --- a/examples/c/admin/list_clients.c +++ b/examples/c/admin/list_clients.c @@ -53,7 +53,7 @@ int main(int argc, char **argv) { int ret = -1; virAdmConnectPtr conn = NULL; - virAdmServerPtr srv = NULL; /* which server list the clients from */ + virAdmServerPtr srv = NULL; /* which server to list the clients from */ virAdmClientPtr *clients = NULL; /* where to store the servers */ ssize_t i = 0; int count = 0; diff --git a/examples/c/admin/logging.c b/examples/c/admin/logging.c index 730ae40d9d53..575d15a3a67c 100644 --- a/examples/c/admin/logging.c +++ b/examples/c/admin/logging.c @@ -77,7 +77,7 @@ int main(int argc, char **argv) goto cleanup; } - /* now, try to change the redefine the current log output and filters */ + /* now, try to change the current log output and filters */ if (virAdmConnectSetLoggingOutputs(conn, set_outputs, 0) < 0) goto cleanup; -- 2.38.1

1 0

[PATCH] selinux: Reflect context_str() type change
by Michal Privoznik 29 Nov '22

29 Nov '22

As of [1]. libselinux changed the type of context_str() - it now returns a const string. Follow this change in our code base. 1: https://github.com/SELinuxProject/selinux/commit/dd98fa322766760c4e1f029cf1… Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/security/security_selinux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 1f72f61cac..92e85c92e0 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -526,7 +526,7 @@ static char * virSecuritySELinuxContextAddRange(char *src, char *dst) { - char *str = NULL; + const char *str = NULL; char *ret = NULL; context_t srccon = NULL; context_t dstcon = NULL; @@ -567,7 +567,7 @@ virSecuritySELinuxGenNewContext(const char *basecontext, { context_t context = NULL; char *ret = NULL; - char *str; + const char *str; char *ourSecContext = NULL; context_t ourContext = NULL; -- 2.37.4

2 1

Entering freeze for libvirt-8.10.0
by Jiri Denemark 29 Nov '22

29 Nov '22

I have just tagged v8.10.0-rc1 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1

[PATCH 0/2] qemu: refresh state after reset
by Kristina Hanicova 29 Nov '22

29 Nov '22

This series implements domain state refreshing after reset from libvirt API and reboot from the guest OS. Kristina Hanicova (2): qemu: refresh state after reset qemu: refresh state after reboot initiated from the guest src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 22 +++++++++++++++++++++- src/qemu/qemu_process.c | 2 ++ 4 files changed, 25 insertions(+), 1 deletion(-) -- 2.38.1

2 3

[PATCH v2] qemu_tpm: Check for qemuTPMSetupEncryption() errors
by Michal Privoznik 29 Nov '22

29 Nov '22

Inside of qemuTPMEmulatorBuildCommand() there are two calls to qemuTPMSetupEncryption() which simply ignore returned error. This is suboptimal because then we rely on swtpm binary reporting a generic error (something among invalid command line arguments) while an error reported by qemuTPMSetupEncryption() is more specific. However, since virCommandSetSendBuffer() only sets an error inside of virCommand structure (the error is then reported in virCommandRun()), we need to exempt its retval from error checking. Thus, the signature of qemuTPMSetupEncryption() is changed a bit so that -1/0 can be returned to indicate error. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://listman.redhat.com/archives/libvir-list/2022-November/235866.html diff to v1: - Ignore error from virCommandSetSendBuffer() as it'll be reported later. Don't actually jump onto error label as it would defeat the purpose. src/qemu/qemu_tpm.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index 15ee7db757..bdce060db8 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -224,20 +224,25 @@ qemuTPMEmulatorDeleteStorage(virDomainTPMDef *tpm) * * @secretuuid: The UUID with the secret holding passphrase * @cmd: the virCommand to transfer the secret to + * @fd: returned read-end of the pipe * - * Returns file descriptor representing the read-end of a pipe. - * The passphrase can be read from this pipe. Returns < 0 in case - * of error. + * Sets @fd to a file descriptor representing the read-end of a + * pipe. The passphrase can be read from this pipe. * * This function reads the passphrase and writes it into the * write-end of a pipe so that the read-end of the pipe can be * passed to the emulator for reading the passphrase from. * - * Note that the returned FD is owned by @cmd. + * Note that the returned @fd is owned by @cmd and thus should + * only be used to append an argument onto emulator cmdline. + * + * Returns: 0 on success, + * -1 otherwise (with proper error reported). */ static int qemuTPMSetupEncryption(const unsigned char *secretuuid, - virCommand *cmd) + virCommand *cmd, + int *fd) { g_autoptr(virConnect) conn = NULL; g_autofree uint8_t *secret = NULL; @@ -260,7 +265,8 @@ qemuTPMSetupEncryption(const unsigned char *secretuuid, &secret, &secret_len) < 0) return -1; - return virCommandSetSendBuffer(cmd, g_steal_pointer(&secret), secret_len); + *fd = virCommandSetSendBuffer(cmd, g_steal_pointer(&secret), secret_len); + return 0; } @@ -322,7 +328,7 @@ qemuTPMVirCommandAddEncryption(virCommand *cmd, return -1; } - if ((pwdfile_fd = qemuTPMSetupEncryption(secretuuid, cmd)) < 0) + if (qemuTPMSetupEncryption(secretuuid, cmd, &pwdfile_fd) < 0) return -1; virCommandAddArg(cmd, "--pwdfile-fd"); @@ -634,8 +640,13 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm, goto error; } - pwdfile_fd = qemuTPMSetupEncryption(tpm->data.emulator.secretuuid, cmd); - migpwdfile_fd = qemuTPMSetupEncryption(tpm->data.emulator.secretuuid, cmd); + if (qemuTPMSetupEncryption(tpm->data.emulator.secretuuid, + cmd, &pwdfile_fd) < 0) + goto error; + + if (qemuTPMSetupEncryption(tpm->data.emulator.secretuuid, + cmd, &migpwdfile_fd) < 0) + goto error; virCommandAddArg(cmd, "--key"); virCommandAddArgFormat(cmd, "pwdfd=%d,mode=aes-256-cbc", pwdfile_fd); -- 2.37.4

2 1

[PATCH] Document caveats of hypervisor-specific stats in 'VIR_DOMAIN_STATS_VCPU' group
by Peter Krempa 29 Nov '22

29 Nov '22

In commit c43718ef67944 I've added a disclaimer that the new stats which are fetched from qemu and passed directly to the user are not guaranteed by libvirt. I didn't notice that per-vcpu hypervisor specific stats are also snuck into the VIR_DOMAIN_STATS_VCPU group along with other pre-existing stats we do guarantee. Extend the disclaimer for VIR_DOMAIN_STATS_VCPU too. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/manpages/virsh.rst | 22 ++++++++++++++++++++++ src/libvirt-domain.c | 17 +++++++++++++++++ 2 files changed, 39 insertions(+) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 5f5f48f83e..1e8a43bc55 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2399,6 +2399,28 @@ When selecting the *--state* group the following fields are returned: host scheduler, but was waiting in the queue instead of running. Exposed to the VM as a steal time. +This group of statistics also reports additional hypervisor-originating per-vCPU +stats. The hypervisor-specific statistics in this group have the following +naming scheme: + + ``vcpu.<num>.$NAME.$TYPE`` + + ``$NAME`` + name of the statistics field provided by the hypervisor + + ``$TYPE`` + Type of the value. The following types are returned: + + ``cur`` + current instant value + ``sum`` + aggregate value + ``max`` + peak value + + The returned value may be either an unsigned long long or a boolean. Meaning + is hypervisor specific. Please see the disclaimer for the *--vm* group which + also consists of hypervisor-specific stats. *--interface* returns: diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 56c2abf3fa..78c26b2219 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -12270,6 +12270,23 @@ virConnectGetDomainCapabilities(virConnectPtr conn, * instead of running. Exposed to the VM as a steal * time. * + * This group of statistics also reports additional hypervisor-originating + * per-vCPU stats. The hypervisor-specific statistics in this group have the + * following naming scheme: + * + * "vcpu.<num>.$NAME.$TYPE" + * + * $NAME - name of the statistics field provided by the hypervisor + * + * $TYPE - Type of the value. The following types are returned: + * 'cur' - current instant value + * 'sum' - aggregate value + * 'max' - peak value + * + * The returned value may be either an unsigned long long or a boolean. + * Meaning is hypervisor specific. Please see the disclaimer for the + * VIR_DOMAIN_STATS_VM group below. + * * VIR_DOMAIN_STATS_INTERFACE: * Return network interface statistics (from domain point of view). * The typed parameter keys are in this format: -- 2.38.1

2 1

[PATCH v3] virsh: Add message to terminal when running snapshot-revert
by Haruka Ohata 29 Nov '22

29 Nov '22

When running virsh snapshot-* command, such as snapshot-create-as / snapshot-delete, it prints a result message. On the other hand virsh snapshot-revert command doesn't print a result message. So, This patch fixes to add message when running virsh snapshot-revert command. --- # virsh snapshot-create-as vm1 test1 Domain snapshot test01 created # virsh snapshot-revert vm1 test1 # virsh snapshot-delete vm1 test1 Domain snapshot test01 deleted # --- Signed-off-by: Haruka Ohata <ohata.haruka(a)fujitsu.com> --- tests/virsh-snapshot | 3 +++ tools/virsh-snapshot.c | 6 +++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/virsh-snapshot b/tests/virsh-snapshot index 4c64bb537b..b09273917b 100755 --- a/tests/virsh-snapshot +++ b/tests/virsh-snapshot @@ -100,11 +100,14 @@ Domain snapshot s1 created Domain snapshot s3 created Domain snapshot s2 created +Domain snapshot s3 reverted Domain snapshot s6 created Domain snapshot s5 created +Domain snapshot s6 reverted Domain snapshot s4 created +Domain snapshot s1 reverted Domain snapshot s7 created Domain snapshot s8 created diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index 8fa64ba903..b7ec675e61 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -1783,7 +1783,11 @@ cmdDomainSnapshotRevert(vshControl *ctl, const vshCmd *cmd) result = virDomainRevertToSnapshot(snapshot, flags); } - return result >= 0; + if (result < 0) + vshError(ctl, _("Failed to revert snapshot %s"), name); + else + vshPrintExtra(ctl, _("Domain snapshot %s reverted\n"), name); + return result; } /* -- 2.38.1

2 1

[libvirt PATCH v2] Add basically RISC-V support
by Yu Gu 29 Nov '22

29 Nov '22

This patch provides basic support for the RISC-V architecture, so libvirt can run in RISC-V machine. Signed-off-by: Yu Gu <guyu2876(a)gmail.com> --- po/POTFILES | 1 + src/cpu/cpu.c | 2 + src/cpu/cpu.h | 2 + src/cpu/cpu_riscv64.c | 118 +++++++++++++++++++++++++++++++ src/cpu/cpu_riscv64.h | 28 ++++++++ src/cpu/cpu_riscv64_data.h | 40 +++++++++++ src/cpu/meson.build | 1 + src/cpu_map/index.xml | 4 ++ src/cpu_map/meson.build | 1 + src/cpu_map/riscv64_vendors.xml | 3 + src/util/virarch.c | 2 + src/util/virhostcpu.c | 2 +- src/util/virsysinfo.c | 121 ++++++++++++++++++++++++++++++++ 13 files changed, 324 insertions(+), 1 deletion(-) create mode 100644 src/cpu/cpu_riscv64.c create mode 100644 src/cpu/cpu_riscv64.h create mode 100644 src/cpu/cpu_riscv64_data.h create mode 100644 src/cpu_map/riscv64_vendors.xml diff --git a/po/POTFILES b/po/POTFILES index 169e2a41dc..a52795e7c1 100644 --- a/po/POTFILES +++ b/po/POTFILES @@ -72,6 +72,7 @@ src/cpu/cpu_map.c src/cpu/cpu_ppc64.c src/cpu/cpu_s390.c src/cpu/cpu_x86.c +src/cpu/cpu_riscv64.c src/datatypes.c src/driver.c src/esx/esx_driver.c diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index d97ef5e873..8fdc42e719 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -27,6 +27,7 @@ #include "cpu_ppc64.h" #include "cpu_s390.h" #include "cpu_arm.h" +#include "cpu_riscv64.h" #include "capabilities.h" @@ -39,6 +40,7 @@ static struct cpuArchDriver *drivers[] = { &cpuDriverPPC64, &cpuDriverS390, &cpuDriverArm, + &cpuDriverRISCV64, }; diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h index 41a62ce486..6e0a06fce4 100644 --- a/src/cpu/cpu.h +++ b/src/cpu/cpu.h @@ -27,6 +27,7 @@ #include "cpu_x86_data.h" #include "cpu_ppc64_data.h" #include "cpu_arm_data.h" +#include "cpu_riscv64_data.h" typedef struct _virCPUData virCPUData; @@ -36,6 +37,7 @@ struct _virCPUData { virCPUx86Data x86; virCPUppc64Data ppc64; virCPUarmData arm; + virCPUriscv64Data riscv64; /* generic driver needs no data */ } data; }; diff --git a/src/cpu/cpu_riscv64.c b/src/cpu/cpu_riscv64.c new file mode 100644 index 0000000000..21f7178cc2 --- /dev/null +++ b/src/cpu/cpu_riscv64.c @@ -0,0 +1,118 @@ +/* + * cpu_riscv64.c: CPU driver for riscv64(x) CPUs + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#include <config.h> + +#include "cpu.h" + + +#define VIR_FROM_THIS VIR_FROM_CPU + +static const virArch archs[] = { VIR_ARCH_RISCV64 }; + +static virCPUCompareResult +virCPUriscv64Compare(virCPUDef *host G_GNUC_UNUSED, + virCPUDef *cpu G_GNUC_UNUSED, + bool failMessages G_GNUC_UNUSED) +{ + /* riscv64 relies on QEMU to perform all runability checking. Return + * VIR_CPU_COMPARE_IDENTICAL to bypass Libvirt checking. + */ + return VIR_CPU_COMPARE_IDENTICAL; +} + +static int +virCPUriscv64Update(virCPUDef *guest, + const virCPUDef *host, + bool relative) +{ + g_autoptr(virCPUDef) updated = NULL; + size_t i; + + if (!relative) + return 0; + + if (guest->mode == VIR_CPU_MODE_CUSTOM) { + if (guest->match == VIR_CPU_MATCH_MINIMUM) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("match mode %s not supported"), + virCPUMatchTypeToString(guest->match)); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("optional CPU features are not supported")); + } + return -1; + } + + if (!host) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("unknown host CPU model")); + return -1; + } + + if (!(updated = virCPUDefCopyWithoutModel(guest))) + return -1; + + updated->mode = VIR_CPU_MODE_CUSTOM; + if (virCPUDefCopyModel(updated, host, true) < 0) + return -1; + + for (i = 0; i < guest->nfeatures; i++) { + if (virCPUDefUpdateFeature(updated, + guest->features[i].name, + guest->features[i].policy) < 0) + return -1; + } + + virCPUDefStealModel(guest, updated, false); + guest->mode = VIR_CPU_MODE_CUSTOM; + guest->match = VIR_CPU_MATCH_EXACT; + + return 0; +} + + +static int +virCPUriscv64ValidateFeatures(virCPUDef *cpu) +{ + size_t i; + + for (i = 0; i < cpu->nfeatures; i++) { + if (cpu->features[i].policy == VIR_CPU_FEATURE_OPTIONAL) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("only cpu feature policies 'require' and " + "'disable' are supported for %s"), + cpu->features[i].name); + return -1; + } + } + + return 0; +} + +struct cpuArchDriver cpuDriverRISCV64 = { + .name = "riscv64", + .arch = archs, + .narch = G_N_ELEMENTS(archs), + .compare = virCPUriscv64Compare, + .decode = NULL, + .encode = NULL, + .baseline = NULL, + .update = virCPUriscv64Update, + .validateFeatures = virCPUriscv64ValidateFeatures, +}; diff --git a/src/cpu/cpu_riscv64.h b/src/cpu/cpu_riscv64.h new file mode 100644 index 0000000000..67528415fe --- /dev/null +++ b/src/cpu/cpu_riscv64.h @@ -0,0 +1,28 @@ +/* + * cpu_riscv64.h: CPU driver for 64-bit RISC-V CPUs + * + * Copyright (C) Copyright (C) IBM Corporation, 2010 + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_CPU_RISCV64_H__ +# define __VIR_CPU_RISCV64_H__ + +# include "cpu.h" + +extern struct cpuArchDriver cpuDriverRISCV64; + +#endif diff --git a/src/cpu/cpu_riscv64_data.h b/src/cpu/cpu_riscv64_data.h new file mode 100644 index 0000000000..819b9e8fde --- /dev/null +++ b/src/cpu/cpu_riscv64_data.h @@ -0,0 +1,40 @@ +/* + * cpu_riscv64_data.h: 64-bit riscv64 CPU specific data + * + * Copyright (C) 2012 IBM Corporation. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_CPU_RISCV64_DATA_H__ +# define __VIR_CPU_RISCV64_DATA_H__ + +# include <stdint.h> + +typedef struct _virCPUriscv64Prid virCPUriscv64Prid; +struct _virCPUriscv64Prid { + uint32_t value; + uint32_t mask; +}; + +# define VIR_CPU_riscv64_DATA_INIT { 0 } + +typedef struct _virCPUriscv64Data virCPUriscv64Data; +struct _virCPUriscv64Data { + size_t len; + virCPUriscv64Prid *prid; +}; + +#endif diff --git a/src/cpu/meson.build b/src/cpu/meson.build index b4ad95e46d..eba1d45743 100644 --- a/src/cpu/meson.build +++ b/src/cpu/meson.build @@ -5,6 +5,7 @@ cpu_sources = [ 'cpu_ppc64.c', 'cpu_s390.c', 'cpu_x86.c', + 'cpu_riscv64.c', ] cpu_lib = static_library( diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index d533a28865..f2c4b1c62a 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -89,6 +89,10 @@ <include filename='ppc64_POWERPC_e6500.xml'/> </arch> + <arch name='riscv64'> + <include filename='riscv64_vendors.xml'/> + </arch> + <arch name='arm'> <include filename='arm_vendors.xml'/> <include filename='arm_features.xml'/> diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index 99264289e2..1a02df8268 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -19,6 +19,7 @@ cpumap_data = [ 'ppc64_POWERPC_e5500.xml', 'ppc64_POWERPC_e6500.xml', 'ppc64_vendors.xml', + 'riscv64_vendors.xml', 'x86_486.xml', 'x86_athlon.xml', 'x86_Broadwell-IBRS.xml', diff --git a/src/cpu_map/riscv64_vendors.xml b/src/cpu_map/riscv64_vendors.xml new file mode 100644 index 0000000000..478a23a467 --- /dev/null +++ b/src/cpu_map/riscv64_vendors.xml @@ -0,0 +1,3 @@ +<cpus> + <vendor name='RISC-V'/> +</cpus> \ No newline at end of file diff --git a/src/util/virarch.c b/src/util/virarch.c index 2134dd6a9d..3d14ecd193 100644 --- a/src/util/virarch.c +++ b/src/util/virarch.c @@ -190,6 +190,8 @@ virArch virArchFromHost(void) return VIR_ARCH_ALPHA; case PROCESSOR_ARCHITECTURE_PPC: return VIR_ARCH_PPC; + case PROCESSOR_ARCHITECTURE_RISCV: + return VIR_ARCH_RISCV64; case PROCESSOR_ARCHITECTURE_SHX: return VIR_ARCH_SH4; case PROCESSOR_ARCHITECTURE_ARM: diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index c1e8dc8078..08c2290f00 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -544,7 +544,7 @@ virHostCPUParseFrequency(FILE *cpuinfo, char line[1024]; /* No sensible way to retrieve CPU frequency */ - if (ARCH_IS_ARM(arch)) + if (ARCH_IS_ARM(arch) || ARCH_IS_RISCV(arch)) return 0; if (ARCH_IS_X86(arch)) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 376d5d4816..e281d928c7 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -623,6 +623,125 @@ virSysinfoReadS390(void) return g_steal_pointer(&ret); } +#if 0 +static int +virSysinfoParseRISCVSystem(const char *base, virSysinfoSystemDef **sysdef) +{ + int ret = -1; + virSysinfoSystemDef *def; + + def = g_new0(virSysinfoSystemDef, 1); + +#if 0 + if (!virSysinfoParseS390Line(base, "Manufacturer", &def->manufacturer)) + goto cleanup; + + if (!virSysinfoParseS390Line(base, "Type", &def->family)) + goto cleanup; +#endif + def->manufacturer = g_strndup("Virt-RISC-V", sizeof("Virt RISC-V")); + + if (!def->manufacturer && !def->product && !def->version && + !def->serial && !def->uuid && !def->sku && !def->family) { + g_clear_pointer(&def, virSysinfoSystemDefFree); + } + + *sysdef = g_steal_pointer(&def); + ret = 0; + cleanup: + virSysinfoSystemDefFree(def); + return ret; +} +#endif + +static int +virSysinfoParseRISCVProcessor(const char *base, virSysinfoDef *ret) +{ + const char *tmp_base; + char *manufacturer = NULL; + char *procline = NULL; + char *ncpu = NULL; + int result = -1; + virSysinfoProcessorDef *processor; + + if (!(tmp_base = virSysinfoParseS390Line(base, "uarch", &manufacturer))) + goto error; + + /* Find processor N: line and gather the processor manufacturer, + version, serial number, and family */ + while ((tmp_base = strstr(tmp_base, "processor ")) + && (tmp_base = virSysinfoParseS390Line(tmp_base, "processor ", + &procline))) { + VIR_EXPAND_N(ret->processor, ret->nprocessor, 1); + processor = &ret->processor[ret->nprocessor - 1]; + processor->processor_manufacturer = g_strdup(manufacturer); + + VIR_FREE(procline); + } + + /* now, for each processor found, extract the frequency information */ + tmp_base = base; + + while ((tmp_base = strstr(tmp_base, "hart")) && + (tmp_base = virSysinfoParseS390Line(tmp_base, "hart", &ncpu))) { + unsigned int n; + char *mhz = NULL; + + if (virStrToLong_uip(ncpu, NULL, 10, &n) < 0) + goto error; + + if (n >= ret->nprocessor) { + VIR_DEBUG("CPU number '%u' out of range", n); + goto cleanup; + } + + VIR_FREE(ncpu); + } + + cleanup: + result = 0; + + error: + VIR_FREE(manufacturer); + VIR_FREE(procline); + VIR_FREE(ncpu); + return result; +} + +virSysinfoDef * +virSysinfoReadRISCV(void) +{ + g_autoptr(virSysinfoDef) ret = NULL; + g_autofree char *outbuf = NULL; + + ret = g_new0(virSysinfoDef, 1); + + /* Gather info from /proc/cpuinfo */ + if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to open %s"), CPUINFO); + return NULL; + } + + if (virSysinfoParseRISCVProcessor(outbuf, ret) < 0) + return NULL; + + /* Free buffer before reading next file */ + VIR_FREE(outbuf); + +#if 0 + /* Gather info from /proc/sysinfo */ + if (virFileReadAll(SYSINFO, 8192, &outbuf) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to open %s"), SYSINFO); + return NULL; + } + + if (virSysinfoParseRISCVSystem(outbuf, &ret->system) < 0) + return NULL; +#endif + return g_steal_pointer(&ret); +} static int virSysinfoParseBIOS(const char *base, virSysinfoBIOSDef **bios) @@ -1243,6 +1362,8 @@ virSysinfoRead(void) return virSysinfoReadPPC(); #elif defined(__arm__) || defined(__aarch64__) return virSysinfoReadARM(); +#elif defined(__riscv) && __riscv_xlen == 64 + return virSysinfoReadRISCV(); #elif defined(__s390__) || defined(__s390x__) return virSysinfoReadS390(); #elif !defined(WIN32) && \ -- 2.37.3

2 2

[PATCH 0/2] Couple of domain <interface/> fixes
by Michal Privoznik 28 Nov '22

28 Nov '22

The first one fixes a bug that was reported on the list: https://listman.redhat.com/archives/libvir-list/2022-November/235922.html The second one - I've noticed while investigating the first one. Michal Prívozník (2): conf: Make VIR_DOMAIN_NET_TYPE_ETHERNET not share 'host view' virnetdevbandwidth: Unbreak tc filter update on Linux-4.20+ src/conf/domain_conf.c | 2 +- src/util/virnetdevbandwidth.c | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) -- 2.37.4

3 4

[PATCH] NEWS: Update for 8.10.0
by Peter Krempa 28 Nov '22

28 Nov '22

Mention 'virt-qemu-sev-validate', SGX EPC, vTPM migration, cpu flag additions and other notable changes in this release. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 2ce8ef4b6a..c119d68da6 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,10 +17,85 @@ v8.10.0 (unreleased) * **New features** + * Tool for validating SEV firmware boot measurement of QEMU VMs + + The ``virt-qemu-sev-validate`` program will compare a reported SEV/SEV-ES + domain launch measurement, to a computed launch measurement. This + determines whether the domain has been tampered with during launch. + + * Support for SGX EPC (enclave page cache) + + Users can add a ``<memory model='sgx-epc'>`` device to lauch a VM with + ``Intel Software Guard Extensions``. + + * Support migration of vTPM state of QEMU vms on shared storage + + Pass ``--migration`` option if appropriate in order for ``swtpm`` to + properly migrate on shared storage. + * **Improvements** + * Mark close callback (un-)register API as high priority + + High priority APIs use a separate thread pool thus can help in eliminating + problems with stuck VMs. Marking the close callback API as high priority + allows ``virsh`` to properly connect to the daemon in case the normal + priority workers are stuck allowing other high priority API usage. + + * Updated x86 CPU features + + The following features for the x86 platform were added: + ``v-vmsave-vmload``, ``vgif``, ``avx512-vp2intersect``, ``avx512-fp16``, + ``serialize``, ``tsx-ldtrk``, ``arch-lbr``, ``xfd``, ``intel-pt-lip``, + ``avic``, ``sgx``, ``sgxlc``, ``sgx-exinfo``, ``sgx1``, ``sgx2``, + ``sgx-debug``, ``sgx-mode64``, ``sgx-provisionkey``, ``sgx-tokenkey``, + ``sgx-kss``, ``bus-lock-detect``, ``pks``, ``amx``. + + * Add support for ``hv-avic`` Hyper-V enlightenment + + ``qemu-6.2`` introduced support for the ``hv-avic`` enlightenment which + allows to use Hyper-V SynIC with hardware APICv/AVIC enabled. + + * qemu: Run memory preallocation with numa-pinned threads + + Run the thread allocating memory in the proper NUMA node to reduce overhead. + + * RPM packaging changes + + - add optional dependancy of ``libvirt-daemon`` on ``libvirt-client`` + + The ``libvirt-guests.`` tool requires the ``virsh`` client to work + properly, but we don't want to require the installation of the daemon + if the tool is not used. + + - relax required ``python3-libvirt`` version for ``libvirt-client-qemu`` + + The ``virt-qemu-qmp-proxy`` tool requires python but doesn't strictly + need the newest version. Remove the strict versioning requirement in + order to prevent cyclic dependency when building. + * **Bug fixes** + * Skip initialization of ``cache`` capabilities if host doesn't support them + + Hypervisor drivers would fail to initialize on ``aarch64`` hosts with + following error :: + + virStateInitialize:657 : Initialisation of cloud-hypervisor state driver failed: no error + + which prevented the startup of the daemon. + + * Allow incoming connections to guests on routed networks w/firewalld + + A change in handling of implicit rules in ``firewalld 1.0.0`` broke + incomming connections to VMs when using ``routed`` network. This is fixed + by adding a new ``libvirt-routed`` zone configured to once again allow + incoming sessions to guests on routed networks. + + * Fix infinite loop in nodedev driver + + Certain udev entries might be of a size that makes libudev emit EINVAL + which caused a busy loop burning CPU. Fix it by ignoring the return code. v8.9.0 (2022-11-01) =================== -- 2.38.1

2 1

[PATCH v2] virsh: Add message to terminal when running snapshot-revert
by Haruka Ohata 28 Nov '22

28 Nov '22

When running virsh snapshot-* command, such as snapshot-create-as / snapshot-delete, it prints a result message. On the other hand virsh snapshot-revert command doesn't print a result message. So, This patch fixes to add message when running virsh snapshot-revert command. --- # virsh snapshot-create-as vm1 test1 Domain snapshot test01 created # virsh snapshot-revert vm1 test1 # virsh snapshot-delete vm1 test1 Domain snapshot test01 deleted # --- Signed-off-by: Haruka Ohata <ohata.haruka(a)fujitsu.com> --- tests/virsh-snapshot | 3 +++ tools/virsh-snapshot.c | 10 +++++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/tests/virsh-snapshot b/tests/virsh-snapshot index 4c64bb537b..b09273917b 100755 --- a/tests/virsh-snapshot +++ b/tests/virsh-snapshot @@ -100,11 +100,14 @@ Domain snapshot s1 created Domain snapshot s3 created Domain snapshot s2 created +Domain snapshot s3 reverted Domain snapshot s6 created Domain snapshot s5 created +Domain snapshot s6 reverted Domain snapshot s4 created +Domain snapshot s1 reverted Domain snapshot s7 created Domain snapshot s8 created diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index 8fa64ba903..4576bf1020 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -1745,7 +1745,7 @@ static const vshCmdOptDef opts_snapshot_revert[] = { }; static bool -cmdDomainSnapshotRevert(vshControl *ctl, const vshCmd *cmd) +cmdSnapshotRevert(vshControl *ctl, const vshCmd *cmd) { g_autoptr(virshDomain) dom = NULL; const char *name = NULL; @@ -1783,7 +1783,11 @@ cmdDomainSnapshotRevert(vshControl *ctl, const vshCmd *cmd) result = virDomainRevertToSnapshot(snapshot, flags); } - return result >= 0; + if (virDomainRevertToSnapshot(snapshot, flags) < 0) + vshError(ctl, _("Failed to revert snapshot %s"), name); + else + vshPrintExtra(ctl, _("Domain snapshot %s reverted\n"), name); + return result; } /* @@ -1916,7 +1920,7 @@ const vshCmdDef snapshotCmds[] = { .flags = 0 }, {.name = "snapshot-revert", - .handler = cmdDomainSnapshotRevert, + .handler = cmdSnapshotRevert, .opts = opts_snapshot_revert, .info = info_snapshot_revert, .flags = 0 -- 2.38.1

2 1

[PATCH] conf: report no NUMA nodes when attaching memory device
by Kristina Hanicova 25 Nov '22

25 Nov '22

Error message reports that the guest has '0' NUMA nodes configured when trying to attach a memory device to a guest with no NUMA nodes. This may be a little misleading because '0' can also be node's id. A more friendly way is to directly report that the guest has no NUMA nodes. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2142519 Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com> --- src/conf/domain_validate.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c index 5bc7ea10aa..95b8d9b419 100644 --- a/src/conf/domain_validate.c +++ b/src/conf/domain_validate.c @@ -2257,6 +2257,12 @@ virDomainMemoryDefValidate(const virDomainMemoryDef *mem, if (mem->targetNode != -1) { const size_t nodeCount = virDomainNumaGetNodeCount(def->numa); + if (nodeCount == 0) { + virReportError(VIR_ERR_XML_DETAIL, "%s", + _("can't add memory backend as guest has no NUMA nodes configured")); + return -1; + } + if (mem->targetNode >= nodeCount) { virReportError(VIR_ERR_XML_DETAIL, _("can't add memory backend for guest node '%d' as the guest has only '%zu' NUMA nodes configured"), -- 2.38.1

2 1

[PATCH v2] cpu_s390: Implement getVendorForModel for IBM Z
by Thomas Huth 25 Nov '22

25 Nov '22

When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Thanks to Boris Fiuczynski for helping with the domaincapsdata! Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- src/cpu/cpu_s390.c | 11 ++ tests/domaincapsdata/qemu_4.2.0.s390x.xml | 144 +++++++++++----------- tests/domaincapsdata/qemu_5.2.0.s390x.xml | 144 +++++++++++----------- tests/domaincapsdata/qemu_6.0.0.s390x.xml | 144 +++++++++++----------- 4 files changed, 227 insertions(+), 216 deletions(-) diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c index d908a83928..7416ec6dc5 100644 --- a/src/cpu/cpu_s390.c +++ b/src/cpu/cpu_s390.c @@ -109,6 +109,16 @@ virCPUs390ValidateFeatures(virCPUDef *cpu) } +static const char * +virCPUs390GetVendorForModel(const char *modelName) +{ + if (modelName[0] == 'z' || STREQLEN(modelName, "gen", 3)) + return "IBM"; + + return NULL; +} + + struct cpuArchDriver cpuDriverS390 = { .name = "s390", .arch = archs, @@ -119,4 +129,5 @@ struct cpuArchDriver cpuDriverS390 = { .baseline = NULL, .update = virCPUs390Update, .validateFeatures = virCPUs390ValidateFeatures, + .getVendorForModel = virCPUs390GetVendorForModel, }; diff --git a/tests/domaincapsdata/qemu_4.2.0.s390x.xml b/tests/domaincapsdata/qemu_4.2.0.s390x.xml index 4f176e2d37..66841881a1 100644 --- a/tests/domaincapsdata/qemu_4.2.0.s390x.xml +++ b/tests/domaincapsdata/qemu_4.2.0.s390x.xml @@ -83,79 +83,79 @@ <feature policy='require' name='cmm'/> </mode> <mode name='custom' supported='yes'> - <model usable='yes' vendor='unknown'>z800-base</model> - <model usable='yes' vendor='unknown'>z890.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.2</model> - <model usable='yes' vendor='unknown'>z13.2</model> - <model usable='yes' vendor='unknown'>z9BC-base</model> - <model usable='yes' vendor='unknown'>z990.5-base</model> - <model usable='yes' vendor='unknown'>z890.2</model> - <model usable='yes' vendor='unknown'>z890</model> - <model usable='yes' vendor='unknown'>z9BC</model> - <model usable='yes' vendor='unknown'>z13</model> - <model usable='yes' vendor='unknown'>z196</model> - <model usable='yes' vendor='unknown'>z13s</model> - <model usable='yes' vendor='unknown'>z990.3</model> - <model usable='yes' vendor='unknown'>z13s-base</model> - <model usable='yes' vendor='unknown'>z9EC</model> - <model usable='yes' vendor='unknown'>gen15a</model> - <model usable='yes' vendor='unknown'>z14ZR1-base</model> - <model usable='yes' vendor='unknown'>z14.2-base</model> - <model usable='yes' vendor='unknown'>z900.3-base</model> - <model usable='yes' vendor='unknown'>z13.2-base</model> - <model usable='yes' vendor='unknown'>z196.2-base</model> - <model usable='yes' vendor='unknown'>zBC12-base</model> - <model usable='yes' vendor='unknown'>z9BC.2-base</model> - <model usable='yes' vendor='unknown'>z900.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.3</model> - <model usable='yes' vendor='unknown'>zEC12</model> - <model usable='yes' vendor='unknown'>z900</model> - <model usable='yes' vendor='unknown'>z114-base</model> - <model usable='yes' vendor='unknown'>zEC12-base</model> - <model usable='yes' vendor='unknown'>z10EC.2</model> - <model usable='yes' vendor='unknown'>z10EC-base</model> - <model usable='yes' vendor='unknown'>z900.3</model> - <model usable='yes' vendor='unknown'>z14ZR1</model> - <model usable='yes' vendor='unknown'>z10BC</model> - <model usable='yes' vendor='unknown'>z10BC.2-base</model> - <model usable='yes' vendor='unknown'>z990.2</model> - <model usable='yes' vendor='unknown'>z9BC.2</model> - <model usable='yes' vendor='unknown'>z990</model> - <model usable='yes' vendor='unknown'>z14</model> - <model usable='yes' vendor='unknown'>gen15b-base</model> - <model usable='yes' vendor='unknown'>z990.4</model> + <model usable='yes' vendor='IBM'>z800-base</model> + <model usable='yes' vendor='IBM'>z890.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.2</model> + <model usable='yes' vendor='IBM'>z13.2</model> + <model usable='yes' vendor='IBM'>z9BC-base</model> + <model usable='yes' vendor='IBM'>z990.5-base</model> + <model usable='yes' vendor='IBM'>z890.2</model> + <model usable='yes' vendor='IBM'>z890</model> + <model usable='yes' vendor='IBM'>z9BC</model> + <model usable='yes' vendor='IBM'>z13</model> + <model usable='yes' vendor='IBM'>z196</model> + <model usable='yes' vendor='IBM'>z13s</model> + <model usable='yes' vendor='IBM'>z990.3</model> + <model usable='yes' vendor='IBM'>z13s-base</model> + <model usable='yes' vendor='IBM'>z9EC</model> + <model usable='yes' vendor='IBM'>gen15a</model> + <model usable='yes' vendor='IBM'>z14ZR1-base</model> + <model usable='yes' vendor='IBM'>z14.2-base</model> + <model usable='yes' vendor='IBM'>z900.3-base</model> + <model usable='yes' vendor='IBM'>z13.2-base</model> + <model usable='yes' vendor='IBM'>z196.2-base</model> + <model usable='yes' vendor='IBM'>zBC12-base</model> + <model usable='yes' vendor='IBM'>z9BC.2-base</model> + <model usable='yes' vendor='IBM'>z900.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.3</model> + <model usable='yes' vendor='IBM'>zEC12</model> + <model usable='yes' vendor='IBM'>z900</model> + <model usable='yes' vendor='IBM'>z114-base</model> + <model usable='yes' vendor='IBM'>zEC12-base</model> + <model usable='yes' vendor='IBM'>z10EC.2</model> + <model usable='yes' vendor='IBM'>z10EC-base</model> + <model usable='yes' vendor='IBM'>z900.3</model> + <model usable='yes' vendor='IBM'>z14ZR1</model> + <model usable='yes' vendor='IBM'>z10BC</model> + <model usable='yes' vendor='IBM'>z10BC.2-base</model> + <model usable='yes' vendor='IBM'>z990.2</model> + <model usable='yes' vendor='IBM'>z9BC.2</model> + <model usable='yes' vendor='IBM'>z990</model> + <model usable='yes' vendor='IBM'>z14</model> + <model usable='yes' vendor='IBM'>gen15b-base</model> + <model usable='yes' vendor='IBM'>z990.4</model> <model usable='yes' vendor='unknown'>max</model> - <model usable='yes' vendor='unknown'>z10EC.2-base</model> - <model usable='yes' vendor='unknown'>gen15a-base</model> - <model usable='yes' vendor='unknown'>z800</model> - <model usable='yes' vendor='unknown'>zEC12.2</model> - <model usable='yes' vendor='unknown'>z10EC</model> - <model usable='yes' vendor='unknown'>z990.2-base</model> - <model usable='yes' vendor='unknown'>z900-base</model> - <model usable='yes' vendor='unknown'>z10BC.2</model> - <model usable='yes' vendor='unknown'>z9EC-base</model> - <model usable='yes' vendor='unknown'>z9EC.3-base</model> - <model usable='yes' vendor='unknown'>z114</model> - <model usable='yes' vendor='unknown'>z890.3</model> - <model usable='yes' vendor='unknown'>z196-base</model> - <model usable='yes' vendor='unknown'>z9EC.2-base</model> - <model usable='yes' vendor='unknown'>z196.2</model> - <model usable='yes' vendor='unknown'>z14.2</model> - <model usable='yes' vendor='unknown'>z990-base</model> - <model usable='yes' vendor='unknown'>z900.2</model> - <model usable='yes' vendor='unknown'>z890-base</model> - <model usable='yes' vendor='unknown'>z10EC.3</model> - <model usable='yes' vendor='unknown'>z14-base</model> - <model usable='yes' vendor='unknown'>z990.4-base</model> - <model usable='yes' vendor='unknown'>z10EC.3-base</model> - <model usable='yes' vendor='unknown'>z10BC-base</model> - <model usable='yes' vendor='unknown'>z13-base</model> - <model usable='yes' vendor='unknown'>z990.3-base</model> - <model usable='yes' vendor='unknown'>zEC12.2-base</model> - <model usable='yes' vendor='unknown'>zBC12</model> - <model usable='yes' vendor='unknown'>z890.3-base</model> - <model usable='yes' vendor='unknown'>z990.5</model> - <model usable='yes' vendor='unknown'>gen15b</model> + <model usable='yes' vendor='IBM'>z10EC.2-base</model> + <model usable='yes' vendor='IBM'>gen15a-base</model> + <model usable='yes' vendor='IBM'>z800</model> + <model usable='yes' vendor='IBM'>zEC12.2</model> + <model usable='yes' vendor='IBM'>z10EC</model> + <model usable='yes' vendor='IBM'>z990.2-base</model> + <model usable='yes' vendor='IBM'>z900-base</model> + <model usable='yes' vendor='IBM'>z10BC.2</model> + <model usable='yes' vendor='IBM'>z9EC-base</model> + <model usable='yes' vendor='IBM'>z9EC.3-base</model> + <model usable='yes' vendor='IBM'>z114</model> + <model usable='yes' vendor='IBM'>z890.3</model> + <model usable='yes' vendor='IBM'>z196-base</model> + <model usable='yes' vendor='IBM'>z9EC.2-base</model> + <model usable='yes' vendor='IBM'>z196.2</model> + <model usable='yes' vendor='IBM'>z14.2</model> + <model usable='yes' vendor='IBM'>z990-base</model> + <model usable='yes' vendor='IBM'>z900.2</model> + <model usable='yes' vendor='IBM'>z890-base</model> + <model usable='yes' vendor='IBM'>z10EC.3</model> + <model usable='yes' vendor='IBM'>z14-base</model> + <model usable='yes' vendor='IBM'>z990.4-base</model> + <model usable='yes' vendor='IBM'>z10EC.3-base</model> + <model usable='yes' vendor='IBM'>z10BC-base</model> + <model usable='yes' vendor='IBM'>z13-base</model> + <model usable='yes' vendor='IBM'>z990.3-base</model> + <model usable='yes' vendor='IBM'>zEC12.2-base</model> + <model usable='yes' vendor='IBM'>zBC12</model> + <model usable='yes' vendor='IBM'>z890.3-base</model> + <model usable='yes' vendor='IBM'>z990.5</model> + <model usable='yes' vendor='IBM'>gen15b</model> <model usable='no' vendor='unknown'>qemu</model> </mode> </cpu> diff --git a/tests/domaincapsdata/qemu_5.2.0.s390x.xml b/tests/domaincapsdata/qemu_5.2.0.s390x.xml index 760f514d7b..31ddbfbc75 100644 --- a/tests/domaincapsdata/qemu_5.2.0.s390x.xml +++ b/tests/domaincapsdata/qemu_5.2.0.s390x.xml @@ -85,79 +85,79 @@ <feature policy='require' name='cmm'/> </mode> <mode name='custom' supported='yes'> - <model usable='yes' vendor='unknown'>z800-base</model> - <model usable='yes' vendor='unknown'>z890.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.2</model> - <model usable='yes' vendor='unknown'>z13.2</model> - <model usable='yes' vendor='unknown'>z990.5-base</model> - <model usable='yes' vendor='unknown'>z9BC-base</model> - <model usable='yes' vendor='unknown'>z890.2</model> - <model usable='yes' vendor='unknown'>z890</model> - <model usable='yes' vendor='unknown'>z9BC</model> - <model usable='yes' vendor='unknown'>z13</model> - <model usable='yes' vendor='unknown'>z196</model> - <model usable='yes' vendor='unknown'>z13s</model> - <model usable='yes' vendor='unknown'>z990.3</model> - <model usable='yes' vendor='unknown'>z13s-base</model> - <model usable='yes' vendor='unknown'>z9EC</model> - <model usable='yes' vendor='unknown'>gen15a</model> - <model usable='yes' vendor='unknown'>z14ZR1-base</model> - <model usable='yes' vendor='unknown'>z14.2-base</model> - <model usable='yes' vendor='unknown'>z900.3-base</model> - <model usable='yes' vendor='unknown'>z13.2-base</model> - <model usable='yes' vendor='unknown'>z196.2-base</model> - <model usable='yes' vendor='unknown'>zBC12-base</model> - <model usable='yes' vendor='unknown'>z9BC.2-base</model> - <model usable='yes' vendor='unknown'>z900.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.3</model> - <model usable='yes' vendor='unknown'>zEC12</model> - <model usable='yes' vendor='unknown'>z900</model> - <model usable='yes' vendor='unknown'>z114-base</model> - <model usable='yes' vendor='unknown'>zEC12-base</model> - <model usable='yes' vendor='unknown'>z10EC.2</model> - <model usable='yes' vendor='unknown'>z10EC-base</model> - <model usable='yes' vendor='unknown'>z900.3</model> - <model usable='yes' vendor='unknown'>z14ZR1</model> - <model usable='yes' vendor='unknown'>z10BC</model> - <model usable='yes' vendor='unknown'>z10BC.2-base</model> - <model usable='yes' vendor='unknown'>z9BC.2</model> - <model usable='yes' vendor='unknown'>z990</model> - <model usable='yes' vendor='unknown'>z990.2</model> - <model usable='yes' vendor='unknown'>z14</model> - <model usable='yes' vendor='unknown'>gen15b-base</model> - <model usable='yes' vendor='unknown'>z990.4</model> + <model usable='yes' vendor='IBM'>z800-base</model> + <model usable='yes' vendor='IBM'>z890.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.2</model> + <model usable='yes' vendor='IBM'>z13.2</model> + <model usable='yes' vendor='IBM'>z990.5-base</model> + <model usable='yes' vendor='IBM'>z9BC-base</model> + <model usable='yes' vendor='IBM'>z890.2</model> + <model usable='yes' vendor='IBM'>z890</model> + <model usable='yes' vendor='IBM'>z9BC</model> + <model usable='yes' vendor='IBM'>z13</model> + <model usable='yes' vendor='IBM'>z196</model> + <model usable='yes' vendor='IBM'>z13s</model> + <model usable='yes' vendor='IBM'>z990.3</model> + <model usable='yes' vendor='IBM'>z13s-base</model> + <model usable='yes' vendor='IBM'>z9EC</model> + <model usable='yes' vendor='IBM'>gen15a</model> + <model usable='yes' vendor='IBM'>z14ZR1-base</model> + <model usable='yes' vendor='IBM'>z14.2-base</model> + <model usable='yes' vendor='IBM'>z900.3-base</model> + <model usable='yes' vendor='IBM'>z13.2-base</model> + <model usable='yes' vendor='IBM'>z196.2-base</model> + <model usable='yes' vendor='IBM'>zBC12-base</model> + <model usable='yes' vendor='IBM'>z9BC.2-base</model> + <model usable='yes' vendor='IBM'>z900.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.3</model> + <model usable='yes' vendor='IBM'>zEC12</model> + <model usable='yes' vendor='IBM'>z900</model> + <model usable='yes' vendor='IBM'>z114-base</model> + <model usable='yes' vendor='IBM'>zEC12-base</model> + <model usable='yes' vendor='IBM'>z10EC.2</model> + <model usable='yes' vendor='IBM'>z10EC-base</model> + <model usable='yes' vendor='IBM'>z900.3</model> + <model usable='yes' vendor='IBM'>z14ZR1</model> + <model usable='yes' vendor='IBM'>z10BC</model> + <model usable='yes' vendor='IBM'>z10BC.2-base</model> + <model usable='yes' vendor='IBM'>z9BC.2</model> + <model usable='yes' vendor='IBM'>z990</model> + <model usable='yes' vendor='IBM'>z990.2</model> + <model usable='yes' vendor='IBM'>z14</model> + <model usable='yes' vendor='IBM'>gen15b-base</model> + <model usable='yes' vendor='IBM'>z990.4</model> <model usable='yes' vendor='unknown'>max</model> - <model usable='yes' vendor='unknown'>z990.2-base</model> - <model usable='yes' vendor='unknown'>z10EC.2-base</model> - <model usable='yes' vendor='unknown'>gen15a-base</model> - <model usable='yes' vendor='unknown'>z800</model> - <model usable='yes' vendor='unknown'>z10EC</model> - <model usable='yes' vendor='unknown'>zEC12.2</model> - <model usable='yes' vendor='unknown'>z900-base</model> - <model usable='yes' vendor='unknown'>z10BC.2</model> - <model usable='yes' vendor='unknown'>z9EC-base</model> - <model usable='yes' vendor='unknown'>z9EC.3-base</model> - <model usable='yes' vendor='unknown'>z114</model> - <model usable='yes' vendor='unknown'>z890.3</model> - <model usable='yes' vendor='unknown'>z196-base</model> - <model usable='yes' vendor='unknown'>z9EC.2-base</model> - <model usable='yes' vendor='unknown'>z196.2</model> - <model usable='yes' vendor='unknown'>z14.2</model> - <model usable='yes' vendor='unknown'>z990-base</model> - <model usable='yes' vendor='unknown'>z900.2</model> - <model usable='yes' vendor='unknown'>z10EC.3</model> - <model usable='yes' vendor='unknown'>z890-base</model> - <model usable='yes' vendor='unknown'>z14-base</model> - <model usable='yes' vendor='unknown'>z990.4-base</model> - <model usable='yes' vendor='unknown'>z10EC.3-base</model> - <model usable='yes' vendor='unknown'>z10BC-base</model> - <model usable='yes' vendor='unknown'>z13-base</model> - <model usable='yes' vendor='unknown'>z990.3-base</model> - <model usable='yes' vendor='unknown'>zEC12.2-base</model> - <model usable='yes' vendor='unknown'>zBC12</model> - <model usable='yes' vendor='unknown'>z890.3-base</model> - <model usable='yes' vendor='unknown'>z990.5</model> - <model usable='yes' vendor='unknown'>gen15b</model> + <model usable='yes' vendor='IBM'>z990.2-base</model> + <model usable='yes' vendor='IBM'>z10EC.2-base</model> + <model usable='yes' vendor='IBM'>gen15a-base</model> + <model usable='yes' vendor='IBM'>z800</model> + <model usable='yes' vendor='IBM'>z10EC</model> + <model usable='yes' vendor='IBM'>zEC12.2</model> + <model usable='yes' vendor='IBM'>z900-base</model> + <model usable='yes' vendor='IBM'>z10BC.2</model> + <model usable='yes' vendor='IBM'>z9EC-base</model> + <model usable='yes' vendor='IBM'>z9EC.3-base</model> + <model usable='yes' vendor='IBM'>z114</model> + <model usable='yes' vendor='IBM'>z890.3</model> + <model usable='yes' vendor='IBM'>z196-base</model> + <model usable='yes' vendor='IBM'>z9EC.2-base</model> + <model usable='yes' vendor='IBM'>z196.2</model> + <model usable='yes' vendor='IBM'>z14.2</model> + <model usable='yes' vendor='IBM'>z990-base</model> + <model usable='yes' vendor='IBM'>z900.2</model> + <model usable='yes' vendor='IBM'>z10EC.3</model> + <model usable='yes' vendor='IBM'>z890-base</model> + <model usable='yes' vendor='IBM'>z14-base</model> + <model usable='yes' vendor='IBM'>z990.4-base</model> + <model usable='yes' vendor='IBM'>z10EC.3-base</model> + <model usable='yes' vendor='IBM'>z10BC-base</model> + <model usable='yes' vendor='IBM'>z13-base</model> + <model usable='yes' vendor='IBM'>z990.3-base</model> + <model usable='yes' vendor='IBM'>zEC12.2-base</model> + <model usable='yes' vendor='IBM'>zBC12</model> + <model usable='yes' vendor='IBM'>z890.3-base</model> + <model usable='yes' vendor='IBM'>z990.5</model> + <model usable='yes' vendor='IBM'>gen15b</model> <model usable='yes' vendor='unknown'>qemu</model> </mode> </cpu> diff --git a/tests/domaincapsdata/qemu_6.0.0.s390x.xml b/tests/domaincapsdata/qemu_6.0.0.s390x.xml index b1968668db..1cb19e051b 100644 --- a/tests/domaincapsdata/qemu_6.0.0.s390x.xml +++ b/tests/domaincapsdata/qemu_6.0.0.s390x.xml @@ -86,79 +86,79 @@ <feature policy='require' name='cmm'/> </mode> <mode name='custom' supported='yes'> - <model usable='yes' vendor='unknown'>z800-base</model> - <model usable='yes' vendor='unknown'>z890.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.2</model> - <model usable='yes' vendor='unknown'>z13.2</model> - <model usable='yes' vendor='unknown'>z990.5-base</model> - <model usable='yes' vendor='unknown'>z9BC-base</model> - <model usable='yes' vendor='unknown'>z890.2</model> - <model usable='yes' vendor='unknown'>z890</model> - <model usable='yes' vendor='unknown'>z9BC</model> - <model usable='yes' vendor='unknown'>z13</model> - <model usable='yes' vendor='unknown'>z196</model> - <model usable='yes' vendor='unknown'>z13s</model> - <model usable='yes' vendor='unknown'>z990.3</model> - <model usable='yes' vendor='unknown'>z13s-base</model> - <model usable='yes' vendor='unknown'>z9EC</model> - <model usable='yes' vendor='unknown'>gen15a</model> - <model usable='yes' vendor='unknown'>z14ZR1-base</model> - <model usable='yes' vendor='unknown'>z14.2-base</model> - <model usable='yes' vendor='unknown'>z900.3-base</model> - <model usable='yes' vendor='unknown'>z13.2-base</model> - <model usable='yes' vendor='unknown'>z196.2-base</model> - <model usable='yes' vendor='unknown'>zBC12-base</model> - <model usable='yes' vendor='unknown'>z9BC.2-base</model> - <model usable='yes' vendor='unknown'>z900.2-base</model> - <model usable='yes' vendor='unknown'>z9EC.3</model> - <model usable='yes' vendor='unknown'>zEC12</model> - <model usable='yes' vendor='unknown'>z900</model> - <model usable='yes' vendor='unknown'>z114-base</model> - <model usable='yes' vendor='unknown'>zEC12-base</model> - <model usable='yes' vendor='unknown'>z10EC.2</model> - <model usable='yes' vendor='unknown'>z10EC-base</model> - <model usable='yes' vendor='unknown'>z900.3</model> - <model usable='yes' vendor='unknown'>z14ZR1</model> - <model usable='yes' vendor='unknown'>z10BC</model> - <model usable='yes' vendor='unknown'>z10BC.2-base</model> - <model usable='yes' vendor='unknown'>z9BC.2</model> - <model usable='yes' vendor='unknown'>z990</model> - <model usable='yes' vendor='unknown'>z990.2</model> - <model usable='yes' vendor='unknown'>z14</model> - <model usable='yes' vendor='unknown'>gen15b-base</model> - <model usable='yes' vendor='unknown'>z990.4</model> + <model usable='yes' vendor='IBM'>z800-base</model> + <model usable='yes' vendor='IBM'>z890.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.2</model> + <model usable='yes' vendor='IBM'>z13.2</model> + <model usable='yes' vendor='IBM'>z990.5-base</model> + <model usable='yes' vendor='IBM'>z9BC-base</model> + <model usable='yes' vendor='IBM'>z890.2</model> + <model usable='yes' vendor='IBM'>z890</model> + <model usable='yes' vendor='IBM'>z9BC</model> + <model usable='yes' vendor='IBM'>z13</model> + <model usable='yes' vendor='IBM'>z196</model> + <model usable='yes' vendor='IBM'>z13s</model> + <model usable='yes' vendor='IBM'>z990.3</model> + <model usable='yes' vendor='IBM'>z13s-base</model> + <model usable='yes' vendor='IBM'>z9EC</model> + <model usable='yes' vendor='IBM'>gen15a</model> + <model usable='yes' vendor='IBM'>z14ZR1-base</model> + <model usable='yes' vendor='IBM'>z14.2-base</model> + <model usable='yes' vendor='IBM'>z900.3-base</model> + <model usable='yes' vendor='IBM'>z13.2-base</model> + <model usable='yes' vendor='IBM'>z196.2-base</model> + <model usable='yes' vendor='IBM'>zBC12-base</model> + <model usable='yes' vendor='IBM'>z9BC.2-base</model> + <model usable='yes' vendor='IBM'>z900.2-base</model> + <model usable='yes' vendor='IBM'>z9EC.3</model> + <model usable='yes' vendor='IBM'>zEC12</model> + <model usable='yes' vendor='IBM'>z900</model> + <model usable='yes' vendor='IBM'>z114-base</model> + <model usable='yes' vendor='IBM'>zEC12-base</model> + <model usable='yes' vendor='IBM'>z10EC.2</model> + <model usable='yes' vendor='IBM'>z10EC-base</model> + <model usable='yes' vendor='IBM'>z900.3</model> + <model usable='yes' vendor='IBM'>z14ZR1</model> + <model usable='yes' vendor='IBM'>z10BC</model> + <model usable='yes' vendor='IBM'>z10BC.2-base</model> + <model usable='yes' vendor='IBM'>z9BC.2</model> + <model usable='yes' vendor='IBM'>z990</model> + <model usable='yes' vendor='IBM'>z990.2</model> + <model usable='yes' vendor='IBM'>z14</model> + <model usable='yes' vendor='IBM'>gen15b-base</model> + <model usable='yes' vendor='IBM'>z990.4</model> <model usable='yes' vendor='unknown'>max</model> - <model usable='yes' vendor='unknown'>z10EC.2-base</model> - <model usable='yes' vendor='unknown'>gen15a-base</model> - <model usable='yes' vendor='unknown'>z800</model> - <model usable='yes' vendor='unknown'>z10EC</model> - <model usable='yes' vendor='unknown'>zEC12.2</model> - <model usable='yes' vendor='unknown'>z990.2-base</model> - <model usable='yes' vendor='unknown'>z900-base</model> - <model usable='yes' vendor='unknown'>z10BC.2</model> - <model usable='yes' vendor='unknown'>z9EC-base</model> - <model usable='yes' vendor='unknown'>z9EC.3-base</model> - <model usable='yes' vendor='unknown'>z114</model> - <model usable='yes' vendor='unknown'>z890.3</model> - <model usable='yes' vendor='unknown'>z196-base</model> - <model usable='yes' vendor='unknown'>z9EC.2-base</model> - <model usable='yes' vendor='unknown'>z196.2</model> - <model usable='yes' vendor='unknown'>z14.2</model> - <model usable='yes' vendor='unknown'>z990-base</model> - <model usable='yes' vendor='unknown'>z900.2</model> - <model usable='yes' vendor='unknown'>z890-base</model> - <model usable='yes' vendor='unknown'>z10EC.3</model> - <model usable='yes' vendor='unknown'>z14-base</model> - <model usable='yes' vendor='unknown'>z990.4-base</model> - <model usable='yes' vendor='unknown'>z10EC.3-base</model> - <model usable='yes' vendor='unknown'>z10BC-base</model> - <model usable='yes' vendor='unknown'>z13-base</model> - <model usable='yes' vendor='unknown'>z990.3-base</model> - <model usable='yes' vendor='unknown'>zEC12.2-base</model> - <model usable='yes' vendor='unknown'>zBC12</model> - <model usable='yes' vendor='unknown'>z890.3-base</model> - <model usable='yes' vendor='unknown'>z990.5</model> - <model usable='yes' vendor='unknown'>gen15b</model> + <model usable='yes' vendor='IBM'>z10EC.2-base</model> + <model usable='yes' vendor='IBM'>gen15a-base</model> + <model usable='yes' vendor='IBM'>z800</model> + <model usable='yes' vendor='IBM'>z10EC</model> + <model usable='yes' vendor='IBM'>zEC12.2</model> + <model usable='yes' vendor='IBM'>z990.2-base</model> + <model usable='yes' vendor='IBM'>z900-base</model> + <model usable='yes' vendor='IBM'>z10BC.2</model> + <model usable='yes' vendor='IBM'>z9EC-base</model> + <model usable='yes' vendor='IBM'>z9EC.3-base</model> + <model usable='yes' vendor='IBM'>z114</model> + <model usable='yes' vendor='IBM'>z890.3</model> + <model usable='yes' vendor='IBM'>z196-base</model> + <model usable='yes' vendor='IBM'>z9EC.2-base</model> + <model usable='yes' vendor='IBM'>z196.2</model> + <model usable='yes' vendor='IBM'>z14.2</model> + <model usable='yes' vendor='IBM'>z990-base</model> + <model usable='yes' vendor='IBM'>z900.2</model> + <model usable='yes' vendor='IBM'>z890-base</model> + <model usable='yes' vendor='IBM'>z10EC.3</model> + <model usable='yes' vendor='IBM'>z14-base</model> + <model usable='yes' vendor='IBM'>z990.4-base</model> + <model usable='yes' vendor='IBM'>z10EC.3-base</model> + <model usable='yes' vendor='IBM'>z10BC-base</model> + <model usable='yes' vendor='IBM'>z13-base</model> + <model usable='yes' vendor='IBM'>z990.3-base</model> + <model usable='yes' vendor='IBM'>zEC12.2-base</model> + <model usable='yes' vendor='IBM'>zBC12</model> + <model usable='yes' vendor='IBM'>z890.3-base</model> + <model usable='yes' vendor='IBM'>z990.5</model> + <model usable='yes' vendor='IBM'>gen15b</model> <model usable='yes' vendor='unknown'>qemu</model> </mode> </cpu> -- 2.31.1

3 3

[PATCH] cpu_s390: Implement getVendorForModel for IBM Z
by Thomas Huth 25 Nov '22

25 Nov '22

When running "virsh domcapabilities" on a s390x host, all the CPU models show up with vendor='unknown' - which sounds kind of weird since the vendor of these mainframe CPUs is well known: IBM. All CPUs starting with either "z" or "gen" match a real mainframe CPU by IBM, so let's return the string "IBM" for those now. The only remaining ones are now the artifical "qemu" and "max" models from QEMU itself, so it should be OK to get an "unknown" vendor for those two. Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- src/cpu/cpu_s390.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c index d908a83928..7416ec6dc5 100644 --- a/src/cpu/cpu_s390.c +++ b/src/cpu/cpu_s390.c @@ -109,6 +109,16 @@ virCPUs390ValidateFeatures(virCPUDef *cpu) } +static const char * +virCPUs390GetVendorForModel(const char *modelName) +{ + if (modelName[0] == 'z' || STREQLEN(modelName, "gen", 3)) + return "IBM"; + + return NULL; +} + + struct cpuArchDriver cpuDriverS390 = { .name = "s390", .arch = archs, @@ -119,4 +129,5 @@ struct cpuArchDriver cpuDriverS390 = { .baseline = NULL, .update = virCPUs390Update, .validateFeatures = virCPUs390ValidateFeatures, + .getVendorForModel = virCPUs390GetVendorForModel, }; -- 2.31.1

2 2

[PATCH 0/2] virsh: Two simple long version output fixes
by Michal Privoznik 24 Nov '22

24 Nov '22

*** BLURB HERE *** Michal Prívozník (2): virsh: Format -V output properly virsh: Report iSCSI-direct backend in long version tools/virsh.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.37.4

2 3

Add option to skip cpu feature and model verification in libvirt and rely on qemu 'enforce' option
by manish.mishra 24 Nov '22

24 Nov '22

Hi Everyone, We had a requirement to skip all CPU feature validations from libvirt and totally rely on Qemu for following reasons. * As libvirt always lies behind in term of cpu feature management compare to qemu, so we may not be able to use all of the latest support provided by qemu till it is updated in libvirt too. For example like if new cpu features are added in qemu but not yet updated in libvirt. * Libvirt does not support cpu model versioning as Qemu. * Libvirt checks if a features is supported or not based on cpuid, a feature supported by host may not be supported by qemu or there can be some features which are emulated by Qemu so libvirt level checking does not make sense in those cases. * Qemu already provide an option 'enforce' to validate if features with which vm is started is exactly same as one provided and nothing is silently dropped. Basically we want another check option like 'qemu-enforce' which will skip all feature and cpu model verfications in libvirt and pass 'enforce' option to qemu. It will work similar to check 'none' i mean no check to verify if provide features are supported by host, also on top of that skip things like virCPUValidateFeatures where ever required. I understand this is specific to just Qemu and libvirt has to take care for many other emulator, so wanted to check if something like that makes sense as it will be very useful for Qemu atleast. If so we can send a patch. Thanks Manish Mishra

4 31