November 2023 - Devel - libvirt List Archives

[libvirt PATCH 0/6] polkit: Make it possible to write safer rules
by Andrea Bolognani 20 Nov '23

20 Nov '23

See patch 5/6 for details. Andrea Bolognani (6): docs: The Polkit access driver is disabled by default docs: Document org.libvirt.unix.* actions rpc: Introduce virNetServerHasGranularPolkit() remote: Set granularPolkit if applicable remote: Expose granularPolkit attribute to rules docs: Document granularPolkit attribute docs/aclpolkit.rst | 33 +++++++++++++++++++++++++++++ src/libvirt_remote.syms | 1 + src/locking/lock_daemon.c | 6 ++++-- src/logging/log_daemon.c | 6 ++++-- src/lxc/lxc_controller.c | 3 ++- src/remote/remote_daemon.c | 24 +++++++++++++++++---- src/remote/remote_daemon_dispatch.c | 6 +++++- src/rpc/virnetserver.c | 16 ++++++++++++-- src/rpc/virnetserver.h | 4 +++- tests/virnetdaemontest.c | 3 ++- 10 files changed, 88 insertions(+), 14 deletions(-) -- 2.42.0

2 7

[libvirt PATCH] kbase: More info on firmware change for existing VMs
by Andrea Bolognani 20 Nov '23

20 Nov '23

The need to remove the <loader> and <nvram> elements in order to make the firmware autoselection process kick in again is not exactly intuitive, so document it explicitly. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/kbase/secureboot.rst | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/docs/kbase/secureboot.rst b/docs/kbase/secureboot.rst index 4340454a7b..6c22b08d22 100644 --- a/docs/kbase/secureboot.rst +++ b/docs/kbase/secureboot.rst @@ -72,16 +72,36 @@ relevant documentation Changing an existing VM ======================= -Once the VM has been created, updating the XML configuration as -described above is **not** enough to change the Secure Boot status: -the NVRAM file associated with the VM has to be regenerated from its -template as well. +When a VM is defined, libvirt will pick the firmware that best +satisfies the provided criteria and record this information for use +on subsequent boots. The resulting XML configuration will look like +this: + +:: + + <os firmware='efi'> + <firmware> + <feature enabled='yes' name='enrolled-keys'/> + <feature enabled='yes' name='secure-boot'/> + </firmware> + <loader readonly='yes' secure='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader> + <nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/vm_VARS.fd</nvram> + </os> + +In order to force libvirt to repeat the firmware autoselection +process, it's necessary to remove the ``<loader>`` and ``<nvram>`` +elements. Failure to do so will likely result in an error. + +Note that updating the XML configuration as described above is +**not** enough to change the Secure Boot status: the NVRAM file +associated with the VM has to be regenerated from its template as +well. In order to do that, update the XML and then start the VM with :: - $ virsh start $vm --reset-nvram + $ virsh start vm --reset-nvram This option is only available starting with libvirt 8.1.0, so if your version of libvirt is older than that you will have to delete the -- 2.41.0

2 1

[PATCH-for-8.2] target/nios2: Deprecate the Nios II architecture
by Philippe Mathieu-Daudé 17 Nov '23

17 Nov '23

See commit 9ba1caf510 ("MAINTAINERS: Mark the Nios II CPU as orphan"), last contribution from Chris was in 2012 [1] and Marek in 2018 [2]. [1] https://lore.kernel.org/qemu-devel/1352607539-10455-2-git-send-email-crwulf… [2] https://lore.kernel.org/qemu-devel/805fc7b5-03f0-56d4-abfd-ed010d4fa769@den… Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- docs/about/deprecated.rst | 15 +++++++++++++++ hw/nios2/10m50_devboard.c | 1 + hw/nios2/generic_nommu.c | 1 + 3 files changed, 17 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 78550c07bf..f7aa556294 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -236,6 +236,16 @@ it. Since all recent x86 hardware from the past >10 years is capable of the 64-bit x86 extensions, a corresponding 64-bit OS should be used instead. +System emulator CPUs +-------------------- + +Nios II CPU (since 8.2) +''''''''''''''''''''''' + +The Nios II architecture is orphan. The ``nios2`` guest CPU support is +deprecated and will be removed in a future version of QEMU. + + System emulator machines ------------------------ @@ -254,6 +264,11 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead. +Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The Nios II architecture is orphan. + Backend options --------------- diff --git a/hw/nios2/10m50_devboard.c b/hw/nios2/10m50_devboard.c index 952a0dc33e..6cb32f777b 100644 --- a/hw/nios2/10m50_devboard.c +++ b/hw/nios2/10m50_devboard.c @@ -160,6 +160,7 @@ static void nios2_10m50_ghrd_class_init(ObjectClass *oc, void *data) mc->desc = "Altera 10M50 GHRD Nios II design"; mc->init = nios2_10m50_ghrd_init; mc->is_default = true; + mc->deprecation_reason = "Nios II architecture is deprecated"; object_class_property_add_bool(oc, "vic", get_vic, set_vic); object_class_property_set_description(oc, "vic", diff --git a/hw/nios2/generic_nommu.c b/hw/nios2/generic_nommu.c index 48edb3ae37..defa16953f 100644 --- a/hw/nios2/generic_nommu.c +++ b/hw/nios2/generic_nommu.c @@ -95,6 +95,7 @@ static void nios2_generic_nommu_machine_init(struct MachineClass *mc) { mc->desc = "Generic NOMMU Nios II design"; mc->init = nios2_generic_nommu_init; + mc->deprecation_reason = "Nios II architecture is deprecated"; } DEFINE_MACHINE("nios2-generic-nommu", nios2_generic_nommu_machine_init); -- 2.41.0

6 5

[libvirt PATCH] rpc: Pass GPG_TTY and TERM environment variables
by Andrea Bolognani 17 Nov '23

17 Nov '23

gpg-agent can be used instead of ssh-agent to authenticate against an SSH server, but in order to do so the GPG_TTY and TERM environment variables need to be passed through. For obvious reasons, we avoid doing that when no_tty=1 is found in the connection URI. https://bugs.debian.org/843863 https://gitlab.com/libvirt/libvirt/-/merge_requests/290 Thanks: Guilhem Moulin <guilhem(a)guilhem.org> Thanks: Kunwu Chan <chentao(a)kylinos.cn> Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- src/rpc/virnetsocket.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index b58f7a6b8f..151077c2dd 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -843,6 +843,11 @@ int virNetSocketNewConnectSSH(const char *nodename, virCommandAddEnvPass(cmd, "OPENSSL_CONF"); virCommandAddEnvPass(cmd, "DISPLAY"); virCommandAddEnvPass(cmd, "XAUTHORITY"); + if (!noTTY) { + /* Needed for gpg-agent's curses-based authentication prompt */ + virCommandAddEnvPass(cmd, "GPG_TTY"); + virCommandAddEnvPass(cmd, "TERM"); + } virCommandClearCaps(cmd); if (service) -- 2.41.0

2 1

[libvirt PATCH] qemu_snapshot: fix reverting to inactive snapshot
by Pavel Hrdina 16 Nov '23

16 Nov '23

When reverting to inactive snapshot updating the domain definition needs to happen after the new overlays are created otherwise qemu-img will correctly fail with error: Trying to create an image with the same filename as the backing file Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 1962ba4027..5fc0b82e79 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -2157,13 +2157,20 @@ qemuSnapshotRevertExternalInactive(virDomainObj *vm, { virQEMUDriver *driver = QEMU_DOMAIN_PRIVATE(vm)->driver; g_autoptr(virBitmap) created = NULL; + int ret = -1; created = virBitmapNew(tmpsnapdef->ndisks); + if (qemuSnapshotCreateQcow2Files(driver, domdef, tmpsnapdef, created) < 0) + goto cleanup; + if (qemuSnapshotDomainDefUpdateDisk(domdef, tmpsnapdef, false) < 0) - return -1; + goto cleanup; - if (qemuSnapshotCreateQcow2Files(driver, domdef, tmpsnapdef, created) < 0) { + ret = 0; + + cleanup: + if (ret < 0 && created) { ssize_t bit = -1; virErrorPtr err = NULL; @@ -2180,11 +2187,9 @@ qemuSnapshotRevertExternalInactive(virDomainObj *vm, } virErrorRestore(&err); - - return -1; } - return 0; + return ret; } -- 2.41.0

2 1

[libvirt PATCH] qemu_snapshot: fix snapshot deletion that had multiple children
by Pavel Hrdina 16 Nov '23

16 Nov '23

When we revert to non-leaf snapshot and create new branch or branches the overlay in snapshot metadata is no longer usable as a disk source for deletion of that snapshot. We need to use other places to figure out the correct storage source. Fixes: https://gitlab.com/libvirt/libvirt/-/issues/534 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 46 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 1962ba4027..ee06e72b11 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -2748,6 +2748,44 @@ qemuSnapshotGetDisksWithBackingStore(virDomainObj *vm, } +/** + * qemuSnapshotExternalGetSnapDiskSrc: + * @vm: domain object + * @snap: snapshot object + * @snapDisk: disk definition from snapshost + * + * Try to get actual disk source for @snapDisk as the source stored in + * snapshot metadata is not always the correct source we need to work with. + * This happens mainly after reverting to non-leaf snapshot and creating + * new branch with new snapshot. + * + * Returns disk source on success, NULL on error. + */ +static virStorageSource * +qemuSnapshotExternalGetSnapDiskSrc(virDomainObj *vm, + virDomainMomentObj *snap, + virDomainSnapshotDiskDef *snapDisk) +{ + virDomainDiskDef *disk = NULL; + + /* Should never happen when deleting external snapshot as for now we do + * not support this specific case for now. */ + if (snap->nchildren > 1) + return snapDisk->src; + + if (snap->first_child) { + disk = qemuDomainDiskByName(snap->first_child->def->dom, snapDisk->name); + } else if (virDomainSnapshotGetCurrent(vm->snapshots) == snap) { + disk = qemuDomainDiskByName(vm->def, snapDisk->name); + } + + if (disk) + return disk->src; + + return snapDisk->src; +} + + /** * qemuSnapshotDeleteExternalPrepareData: * @vm: domain object @@ -2802,18 +2840,22 @@ qemuSnapshotDeleteExternalPrepareData(virDomainObj *vm, } if (data->merge) { + virStorageSource *snapDiskSrc = NULL; + data->domDisk = qemuDomainDiskByName(vm->def, snapDisk->name); if (!data->domDisk) return -1; + snapDiskSrc = qemuSnapshotExternalGetSnapDiskSrc(vm, snap, data->snapDisk); + if (virDomainObjIsActive(vm)) { data->diskSrc = virStorageSourceChainLookupBySource(data->domDisk->src, - data->snapDisk->src, + snapDiskSrc, &data->prevDiskSrc); if (!data->diskSrc) return -1; - if (!virStorageSourceIsSameLocation(data->diskSrc, data->snapDisk->src)) { + if (!virStorageSourceIsSameLocation(data->diskSrc, snapDiskSrc)) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("VM disk source and snapshot disk source are not the same")); return -1; -- 2.41.0

2 1

[libvirt PATCH 0/3] Introduce VIR_MIGRATE_ASSUME_SHARED_STORAGE
by Andrea Bolognani 13 Nov '23

13 Nov '23

This was initially motivated by a KubeVirt issue[1] concerning integration with the Portworx storage provide, but it turns out to be more generally applicable: since mounting an NFS share on the same host that is exporting it is known to cause issues and is therefore not recommended, we need a way to allow migration in such a configuration while still not going quite as far as VIR_MIGRATE_UNSAFE does and losing all handrails. [1] https://issues.redhat.com/browse/CNV-34322 Andrea Bolognani (3): include: Introduce VIR_MIGRATE_ASSUME_SHARED_STORAGE qemu: Implement VIR_MIGRATE_ASSUME_SHARED_STORAGE support virsh: Wire up VIR_MIGRATE_ASSUME_SHARED_STORAGE support docs/manpages/virsh.rst | 5 ++++- include/libvirt/libvirt-domain.h | 14 ++++++++++++++ src/qemu/qemu_migration.c | 5 +++++ src/qemu/qemu_migration.h | 1 + tools/virsh-domain.c | 5 +++++ 5 files changed, 29 insertions(+), 1 deletion(-) -- 2.41.0

3 11

[v2 0/4] Support for dirty-limit live migration
by Hyman Huang 12 Nov '23

12 Nov '23

Hello, this is series version 2. Just certain that it won't be overlooked. Please review, thanks, Yong v2: - rebase on master v1: In qemu>=8.1, the dirty-limit functionality for live migration was included. In the live migration scenario, it implements the force convergence using the dirty-limit approach, which results in better reliable read performance. A straightforward dirty-limit capability for live migration is added by this patchset. Users might not care about other dirty-limit arguments like "x-vcpu-dirty-limit-period" or "vcpu-dirty-limit," thus do not expose them to Libvirt and leave the default settings in place. values as default. For more details about dirty-limit. please see the following reference: https://lore.kernel.org/qemu- devel/169024923116.19090.10825599068950039132-0(a)git.sr.ht/ Hyman Huang (4): Add VIR_MIGRATE_DIRTY_LIMIT flag qemu_migration: Implement VIR_MIGRATE_DIRTY_LIMIT flag virsh: Add support for VIR_MIGRATE_DIRTY_LIMIT flag NEWS: document support for dirty-limit live migration NEWS.rst | 8 ++++++++ docs/manpages/virsh.rst | 10 +++++++++- include/libvirt/libvirt-domain.h | 5 +++++ src/libvirt-domain.c | 8 ++++++++ src/qemu/qemu_migration.c | 8 ++++++++ src/qemu/qemu_migration.h | 1 + src/qemu/qemu_migration_params.c | 6 ++++++ src/qemu/qemu_migration_params.h | 1 + tools/virsh-domain.c | 10 ++++++++++ 9 files changed, 56 insertions(+), 1 deletion(-) -- 2.39.1

1 4

[libvirt PATCH 00/19] RFC: Add versioned CPUs to libvirt
by Jonathon Jongsma 10 Nov '23

10 Nov '23

This is not necessarily intended as a finished proposal, but as a discussion starter. I mentioned in an email last week that for SEV-SNP support we will need to be able to specify versioned CPU models that are not yet supported by libvirt. Rather than just adding a versioned CPU or two that would satisfy my immediate need, I decided to try to add versioned CPUs in a standard way. This involves adding the concept of an 'alias' for a CPU model in libvirt. Qemu already has the concept of a CPU alias for a versioned CPU. In fact, libvirt already provides a select subset of these as configurable CPU models (e.g. 'EPYC-IBPB'). After this patchset, these aliased CPU versions would be configurable by either their versioned name ('EPYC-v2') or their alias ('EPYC-IBPB'). And it would also provide non-aliased CPU versions as options within libvirt ('EPYC-v4'). Assuming that we want to offer all versioned CPUs like this, there are two approaches to naming. I chose to maintain the existing names (e.g. EPYC-IBPB) as the primary name where available, and use the versioned name (EPYC-v2) as the alias. However, some CPU models don't have an alias, so their versioned name would be their primary name. So we have the following set of 'EPYC' CPU models: - EPYC (alias = EPYC-v1) - EPYC-IBPB (alias = EPYC-v2) - EPYC-v3 (no alias) - EPYC-v4 (no alias) An alternative approach is something more like: - EPYC-v1 (alias = EPYC) - EPYC-v2 (alias = EPYC-IBPB) - EPYC-v3 (no alias) - EPYC-v4 (no alias) The naming of the second set is more consistent, but it could result in slight changes to behavior. For example, any call to cpuDecode() that returned EPYC-IBPB in the past might now return EPYC-v2. These two CPUs are just two different names for the same model, so I'm not sure it would result in any issues. But in this patch series I went with the first approach since it maintained stability and resulted in less churn in the test output. Note also that there are a couple of patches that update existing CPU models by re-running this script against the current qemu source code. For example, the patch "cpu_map: Update EPYC cpu definitions from qemu" results in some minor changes to the existing EPYC CPUs by adding a couple of feature flags. In theory, it seems like a good idea for our libvirt models to match how the model is defined in qemu, but I admit that I don't have a great understanding of whether this will result in undesirable side-effects. I'm hoping those of you with deeper knowledge will tell me why this is or is not a good idea. In the same vein, I've included the last patch of the series showing what it would look like if we regenerated all of the other CPU definitions from the qemu source code. Jonathon Jongsma (19): cpu_map: update script to generate versioned CPUs cpu: handle aliases in CPU definitions cpu_map: Update EPYC cpu definitions from qemu cpu_map: Add versioned EPYC CPUs cpu_map: Add versioned Intel Nehalem CPUs cpu_map: Add versioned Intel Westmere CPUs cpu_map: Add versioned Intel SandyBridge CPUs cpu_map: Add versioned Intel IvyBridge CPUs cpu_map: Add versioned Intel Haswell CPUs cpu_map: Add versioned Intel Broadwell CPUs cpu_map: Add versioned Intel Skylake CPUs cpu_map: Add versioned Intel Cascadelake CPUs cpu_map: Add versioned Intel Icelake CPUs cpu_map: Add versioned Intel Cooperlake CPUs cpu_map: Add versioned Intel Snowridge CPUs cpu_map: Add versioned Intel SapphireRapids CPUs cpu_map: Add versioned Dhyana CPUs cpu: advertise CPU aliases NOMERGE: RFC: regenerate all cpu definitions src/cpu/cpu_x86.c | 88 ++++++++---- src/cpu_map/index.xml | 22 +++ src/cpu_map/meson.build | 22 +++ src/cpu_map/sync_qemu_models_i386.py | 44 ++++-- src/cpu_map/x86_Broadwell-IBRS.xml | 19 ++- src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 19 ++- src/cpu_map/x86_Broadwell-noTSX.xml | 19 ++- src/cpu_map/x86_Broadwell.xml | 18 ++- src/cpu_map/x86_Cascadelake-Server-noTSX.xml | 19 ++- src/cpu_map/x86_Cascadelake-Server-v2.xml | 93 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v4.xml | 91 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v5.xml | 92 +++++++++++++ src/cpu_map/x86_Cascadelake-Server.xml | 11 +- src/cpu_map/x86_Cooperlake-v2.xml | 98 ++++++++++++++ src/cpu_map/x86_Cooperlake.xml | 9 +- src/cpu_map/x86_Dhyana-v2.xml | 81 ++++++++++++ src/cpu_map/x86_Dhyana.xml | 13 +- src/cpu_map/x86_EPYC-Genoa.xml | 7 + src/cpu_map/x86_EPYC-IBPB.xml | 14 +- src/cpu_map/x86_EPYC-Milan-v2.xml | 108 +++++++++++++++ src/cpu_map/x86_EPYC-Milan.xml | 8 ++ src/cpu_map/x86_EPYC-Rome-v2.xml | 93 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v3.xml | 95 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v4.xml | 94 +++++++++++++ src/cpu_map/x86_EPYC-Rome.xml | 9 ++ src/cpu_map/x86_EPYC-v3.xml | 87 ++++++++++++ src/cpu_map/x86_EPYC-v4.xml | 88 ++++++++++++ src/cpu_map/x86_EPYC.xml | 13 +- src/cpu_map/x86_Haswell-IBRS.xml | 20 ++- src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 20 ++- src/cpu_map/x86_Haswell-noTSX.xml | 20 ++- src/cpu_map/x86_Haswell.xml | 18 ++- src/cpu_map/x86_Icelake-Server-noTSX.xml | 14 +- src/cpu_map/x86_Icelake-Server-v3.xml | 103 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v4.xml | 108 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v5.xml | 109 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v6.xml | 109 +++++++++++++++ src/cpu_map/x86_Icelake-Server.xml | 11 +- src/cpu_map/x86_IvyBridge-IBRS.xml | 13 +- src/cpu_map/x86_IvyBridge.xml | 12 +- src/cpu_map/x86_Nehalem-IBRS.xml | 14 +- src/cpu_map/x86_Nehalem.xml | 13 +- src/cpu_map/x86_SandyBridge-IBRS.xml | 14 +- src/cpu_map/x86_SandyBridge.xml | 13 +- src/cpu_map/x86_SapphireRapids-v2.xml | 125 ++++++++++++++++++ src/cpu_map/x86_SapphireRapids.xml | 7 + src/cpu_map/x86_Skylake-Client-IBRS.xml | 16 ++- src/cpu_map/x86_Skylake-Client-noTSX-IBRS.xml | 18 +-- src/cpu_map/x86_Skylake-Client-v4.xml | 77 +++++++++++ src/cpu_map/x86_Skylake-Client.xml | 15 ++- src/cpu_map/x86_Skylake-Server-IBRS.xml | 12 +- src/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml | 14 +- src/cpu_map/x86_Skylake-Server-v4.xml | 83 ++++++++++++ src/cpu_map/x86_Skylake-Server-v5.xml | 85 ++++++++++++ src/cpu_map/x86_Skylake-Server.xml | 12 +- src/cpu_map/x86_Snowridge-v2.xml | 78 +++++++++++ src/cpu_map/x86_Snowridge-v3.xml | 80 +++++++++++ src/cpu_map/x86_Snowridge-v4.xml | 78 +++++++++++ src/cpu_map/x86_Snowridge.xml | 10 +- src/cpu_map/x86_Westmere-IBRS.xml | 13 +- src/cpu_map/x86_Westmere.xml | 14 +- ...4-baseline-Westmere+Nehalem-migratable.xml | 4 +- ...86_64-baseline-Westmere+Nehalem-result.xml | 4 +- .../x86_64-baseline-features-expanded.xml | 1 + .../x86_64-baseline-features-result.xml | 2 - .../x86_64-baseline-simple-expanded.xml | 3 + .../x86_64-cpuid-Atom-P5362-guest.xml | 3 +- .../x86_64-cpuid-Atom-P5362-host.xml | 3 - .../x86_64-cpuid-Atom-P5362-json.xml | 3 +- .../x86_64-cpuid-Cooperlake-host.xml | 3 +- .../x86_64-cpuid-Core-i5-2500-guest.xml | 3 - .../x86_64-cpuid-Core-i5-2500-host.xml | 3 - .../x86_64-cpuid-Core-i5-2500-json.xml | 3 - .../x86_64-cpuid-Core-i5-2540M-guest.xml | 3 - .../x86_64-cpuid-Core-i5-2540M-host.xml | 3 - .../x86_64-cpuid-Core-i5-2540M-json.xml | 3 - .../x86_64-cpuid-Core-i5-4670T-guest.xml | 6 +- .../x86_64-cpuid-Core-i5-4670T-host.xml | 19 ++- .../x86_64-cpuid-Core-i5-4670T-json.xml | 6 +- .../x86_64-cpuid-Core-i5-650-guest.xml | 3 - .../x86_64-cpuid-Core-i5-650-host.xml | 3 - .../x86_64-cpuid-Core-i5-650-json.xml | 3 - .../x86_64-cpuid-Core-i5-6600-guest.xml | 1 + .../x86_64-cpuid-Core-i5-6600-host.xml | 1 + .../x86_64-cpuid-Core-i5-6600-json.xml | 1 + .../x86_64-cpuid-Core-i7-2600-guest.xml | 3 - .../x86_64-cpuid-Core-i7-2600-host.xml | 3 - .../x86_64-cpuid-Core-i7-2600-json.xml | 3 - ...6_64-cpuid-Core-i7-2600-xsaveopt-guest.xml | 2 - ...86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 9 +- ...86_64-cpuid-Core-i7-2600-xsaveopt-json.xml | 2 - .../x86_64-cpuid-Core-i7-3520M-guest.xml | 2 - .../x86_64-cpuid-Core-i7-3520M-host.xml | 2 - .../x86_64-cpuid-Core-i7-3740QM-guest.xml | 2 +- .../x86_64-cpuid-Core-i7-3740QM-host.xml | 13 +- .../x86_64-cpuid-Core-i7-3740QM-json.xml | 2 +- .../x86_64-cpuid-Core-i7-3770-guest.xml | 2 - .../x86_64-cpuid-Core-i7-3770-host.xml | 2 - .../x86_64-cpuid-Core-i7-3770-json.xml | 2 +- .../x86_64-cpuid-Core-i7-4510U-guest.xml | 6 - .../x86_64-cpuid-Core-i7-4510U-host.xml | 3 - .../x86_64-cpuid-Core-i7-4510U-json.xml | 6 - .../x86_64-cpuid-Core-i7-4600U-guest.xml | 6 - .../x86_64-cpuid-Core-i7-4600U-host.xml | 6 - .../x86_64-cpuid-Core-i7-4600U-json.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-arat-guest.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-arat-host.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-arat-json.xml | 6 +- .../x86_64-cpuid-Core-i7-5600U-guest.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-host.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-ibrs-guest.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-ibrs-host.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-ibrs-json.xml | 6 - .../x86_64-cpuid-Core-i7-5600U-json.xml | 6 - .../x86_64-cpuid-Core-i7-7600U-guest.xml | 1 + .../x86_64-cpuid-Core-i7-7600U-host.xml | 1 + .../x86_64-cpuid-Core-i7-7600U-json.xml | 1 + .../x86_64-cpuid-Core-i7-7700-guest.xml | 1 + .../x86_64-cpuid-Core-i7-7700-host.xml | 1 + .../x86_64-cpuid-Core-i7-7700-json.xml | 1 + .../x86_64-cpuid-Core-i7-8550U-guest.xml | 5 +- .../x86_64-cpuid-Core-i7-8550U-host.xml | 4 +- .../x86_64-cpuid-Core-i7-8550U-json.xml | 5 +- .../x86_64-cpuid-Core-i7-8700-guest.xml | 1 + .../x86_64-cpuid-Core-i7-8700-host.xml | 1 + .../x86_64-cpuid-Core-i7-8700-json.xml | 1 + .../x86_64-cpuid-EPYC-7502-32-Core-guest.xml | 1 - .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +- .../x86_64-cpuid-EPYC-7502-32-Core-json.xml | 1 - .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 9 +- .../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 2 - ..._64-cpuid-EPYC-7601-32-Core-ibpb-guest.xml | 2 - ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-json.xml | 3 - .../x86_64-cpuid-EPYC-7601-32-Core-json.xml | 3 - ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 3 - .../x86_64-cpuid-Ice-Lake-Server-guest.xml | 1 + .../x86_64-cpuid-Ice-Lake-Server-host.xml | 1 + .../x86_64-cpuid-Ice-Lake-Server-json.xml | 2 +- .../x86_64-cpuid-Pentium-P6100-guest.xml | 10 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 9 +- ...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 2 - ...64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml | 3 - ...6_64-cpuid-Ryzen-9-3900X-12-Core-guest.xml | 1 - ...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml | 1 - ...86_64-cpuid-Ryzen-9-3900X-12-Core-json.xml | 1 - .../x86_64-cpuid-Xeon-E3-1225-v5-guest.xml | 1 + .../x86_64-cpuid-Xeon-E3-1225-v5-host.xml | 1 + .../x86_64-cpuid-Xeon-E3-1225-v5-json.xml | 1 + .../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 1 + .../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 1 + .../x86_64-cpuid-Xeon-E3-1245-v5-json.xml | 1 + .../x86_64-cpuid-Xeon-E5-2609-v3-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2609-v3-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2609-v3-json.xml | 6 - .../x86_64-cpuid-Xeon-E5-2623-v4-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2623-v4-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2623-v4-json.xml | 6 - .../x86_64-cpuid-Xeon-E5-2630-v3-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2630-v3-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2630-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2630-v4-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2630-v4-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2630-v4-json.xml | 6 - .../x86_64-cpuid-Xeon-E5-2650-guest.xml | 3 - .../x86_64-cpuid-Xeon-E5-2650-host.xml | 3 - .../x86_64-cpuid-Xeon-E5-2650-json.xml | 3 - .../x86_64-cpuid-Xeon-E5-2650-v3-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2650-v3-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2650-v3-json.xml | 6 +- .../x86_64-cpuid-Xeon-E5-2650-v4-guest.xml | 6 - .../x86_64-cpuid-Xeon-E5-2650-v4-host.xml | 6 - .../x86_64-cpuid-Xeon-E5-2650-v4-json.xml | 6 - .../x86_64-cpuid-Xeon-E7-4820-guest.xml | 3 - .../x86_64-cpuid-Xeon-E7-4820-host.xml | 3 - .../x86_64-cpuid-Xeon-E7-4820-json.xml | 4 +- .../x86_64-cpuid-Xeon-E7-4830-guest.xml | 3 - .../x86_64-cpuid-Xeon-E7-4830-host.xml | 3 - .../x86_64-cpuid-Xeon-E7-4830-json.xml | 3 - .../x86_64-cpuid-Xeon-E7-8890-v3-guest.xml | 6 - .../x86_64-cpuid-Xeon-E7-8890-v3-host.xml | 6 - .../x86_64-cpuid-Xeon-E7-8890-v3-json.xml | 6 - .../x86_64-cpuid-Xeon-E7540-guest.xml | 1 - .../x86_64-cpuid-Xeon-E7540-host.xml | 1 - .../x86_64-cpuid-Xeon-E7540-json.xml | 1 - .../x86_64-cpuid-Xeon-Gold-5115-guest.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-5115-host.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-5115-json.xml | 2 + .../x86_64-cpuid-Xeon-Gold-6130-guest.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6130-host.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6130-json.xml | 2 +- .../x86_64-cpuid-Xeon-Gold-6148-guest.xml | 3 +- .../x86_64-cpuid-Xeon-Gold-6148-host.xml | 3 +- .../x86_64-cpuid-Xeon-Gold-6148-json.xml | 3 +- .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-json.xml | 2 +- .../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 9 +- .../x86_64-cpuid-Xeon-W3520-guest.xml | 1 - .../x86_64-cpuid-Xeon-W3520-host.xml | 1 - .../x86_64-cpuid-Xeon-W3520-json.xml | 1 - ...id-baseline-Broadwell-IBRS+Cascadelake.xml | 6 - ..._64-cpuid-baseline-Cascadelake+Icelake.xml | 9 +- ...puid-baseline-Cascadelake+Skylake-IBRS.xml | 2 +- ..._64-cpuid-baseline-Cascadelake+Skylake.xml | 3 +- ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 9 +- ...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 9 +- .../x86_64-cpuid-baseline-EPYC+Rome.xml | 3 - .../x86_64-cpuid-baseline-Haswell+Skylake.xml | 6 - ...-baseline-Haswell-noTSX-IBRS+Broadwell.xml | 6 - ...seline-Haswell-noTSX-IBRS+Skylake-IBRS.xml | 6 - ...id-baseline-Haswell-noTSX-IBRS+Skylake.xml | 6 - .../x86_64-cpuid-baseline-Ryzen+Rome.xml | 3 - ...4-cpuid-baseline-Skylake-Client+Server.xml | 1 + .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 33 +++++ .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 32 +++++ tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 33 +++++ .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 37 ++++++ .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 36 +++++ tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 37 ++++++ .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 40 +++++- .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 39 ++++++ tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 40 +++++- .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 40 +++++- .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 39 ++++++ tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 40 +++++- .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 42 +++++- .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 41 ++++++ tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 42 +++++- .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 49 ++++++- .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 48 +++++++ tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 49 ++++++- .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 50 ++++++- .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 49 +++++++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 50 ++++++- .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 51 ++++++- .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 50 +++++++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 51 ++++++- .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 51 ++++++- .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 50 +++++++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 51 ++++++- .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 51 ++++++- .../qemu_7.2.0-tcg.x86_64+hvf.xml | 51 ++++++- .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 51 ++++++- tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 51 ++++++- .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 52 +++++++- .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 52 +++++++- tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 52 +++++++- .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 61 ++++++++- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 57 +++++++- tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 61 ++++++++- .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 61 ++++++++- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 57 +++++++- tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 61 ++++++++- ...-Icelake-Server-pconfig.x86_64-latest.args | 2 +- .../cpu-fallback.x86_64-5.2.0.args | 2 +- .../cpu-fallback.x86_64-8.0.0.args | 2 +- tests/qemuxml2argvdata/cpu-fallback.xml | 1 - .../cpu-host-model-fallback.x86_64-7.2.0.args | 2 +- .../cpu-host-model-fallback.x86_64-8.0.0.args | 2 +- ...cpu-host-model-fallback.x86_64-latest.args | 2 +- ...pu-host-model-nofallback.x86_64-7.2.0.args | 2 +- ...pu-host-model-nofallback.x86_64-8.0.0.args | 2 +- ...u-host-model-nofallback.x86_64-latest.args | 2 +- .../cpu-host-model.x86_64-4.2.0.args | 2 +- .../cpu-host-model.x86_64-5.0.0.args | 2 +- .../cpu-host-model.x86_64-5.1.0.args | 2 +- .../cpu-host-model.x86_64-5.2.0.args | 2 +- .../cpu-host-model.x86_64-6.0.0.args | 2 +- .../cpu-host-model.x86_64-6.1.0.args | 2 +- .../cpu-host-model.x86_64-6.2.0.args | 2 +- .../cpu-host-model.x86_64-7.0.0.args | 2 +- .../cpu-host-model.x86_64-7.1.0.args | 2 +- .../cpu-host-model.x86_64-7.2.0.args | 2 +- .../cpu-host-model.x86_64-8.0.0.args | 2 +- .../cpu-host-model.x86_64-latest.args | 2 +- .../cpu-nofallback.x86_64-8.0.0.args | 2 +- tests/qemuxml2argvdata/cpu-nofallback.xml | 1 - 282 files changed, 4591 insertions(+), 692 deletions(-) create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml create mode 100644 src/cpu_map/x86_Dhyana-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml create mode 100644 src/cpu_map/x86_EPYC-v3.xml create mode 100644 src/cpu_map/x86_EPYC-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml create mode 100644 src/cpu_map/x86_Snowridge-v2.xml create mode 100644 src/cpu_map/x86_Snowridge-v3.xml create mode 100644 src/cpu_map/x86_Snowridge-v4.xml -- 2.41.0

2 21

Versioned CPU types in libvirt
by Jonathon Jongsma 10 Nov '23

10 Nov '23

I'm currently looking at getting libvirt working with AMD's SEV-SNP encrypted virtualization technology. I have access to a test machine with an AMD EPYC 7713 processor which I can use to launch SNP guests with qemu, but only when I specify one of the following versioned -cpu values: - EPYC-v4 - EPYC-Milan-v2 - EPYC-Rome-v3 From what I understand, the unversioned CPU models in qemu are supposed to resolve to a specific versioned CPU model depending on the machine type. But I'm not exactly sure how machine type influences it. I've got some libvirt patches to launch an SEV-SNP guest working now except for the CPU model specification. As far as I can tell, I can currently only specify the un-versioned model in libvirt. Is there any way to request a particular versioned CPU from qemu? I feel like I'm missing something here. I should perhaps also mention that I'm running a development version of qemu from Cole's copr repo[1], which could still have some related bugs [1] https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/sev-snp-coconut/ Thanks, Jonathon

5 7