- Devel - libvirt List Archives

[PATCH] qemu: tpm: Account for possible migration without actually sharing storage
by Peter Krempa 08 Dec '25

08 Dec '25

From: Peter Krempa <pkrempa(a)redhat.com> The current logic in 'qemuTPMEmulatorBuildCommand' skips all setup if the *location* of the data is on what we'd consider shared storage. This means that if the location is not actually shared (e.g. it's shared betweeh some other hosts than the two doing the migration) and the path wasn't ever used (e.g. by migrating out) from the host where we're migrating into the complete setup of the location would be skipped even when it doesn't exist. Fix the logic by skipping only some of the setup steps so that 'qemuTPMEmulatorCreateStorage' can still create the storage if it doesn't exist. The rest of the code then needs to take the 'created' flag returned from 'qemuTPMEmulatorCreateStorage' into account. Fixes: 68103e9daf633b789428fedef56f816c92f6ee75 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_tpm.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_tpm.c b/src/qemu/qemu_tpm.c index 4c9445d72c..1ce6390fd5 100644 --- a/src/qemu/qemu_tpm.c +++ b/src/qemu/qemu_tpm.c @@ -158,6 +158,7 @@ qemuTPMEmulatorGetPid(const char *swtpmStateDir, /** * qemuTPMEmulatorCreateStorage: * @tpm: TPM definition for an emulator type + * @sharedStorageMigration: VM is being migrated with possibly shared storage * @created: a pointer to a bool that will be set to true if the * storage was created because it did not exist yet * @swtpm_user: The uid that needs to be able to access the directory @@ -169,6 +170,7 @@ qemuTPMEmulatorGetPid(const char *swtpmStateDir, */ static int qemuTPMEmulatorCreateStorage(virDomainTPMDef *tpm, + bool sharedStorageMigration, bool *created, uid_t swtpm_user, gid_t swtpm_group) @@ -187,8 +189,14 @@ qemuTPMEmulatorCreateStorage(virDomainTPMDef *tpm, *created = false; if (!virFileExists(source_path) || - virDirIsEmpty(source_path, true) > 0) + virDirIsEmpty(source_path, true) > 0) { *created = true; + } else { + /* If the location exists and is shared, we don't need to create it + * during migration */ + if (sharedStorageMigration) + return 0; + } if (virDirCreate(source_path, 0700, swtpm_user, swtpm_group, VIR_DIR_CREATE_ALLOW_EXIST) < 0) { @@ -809,16 +817,13 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm, run_setup = true; } - /* Do not create storage and run swtpm_setup on incoming migration over - * shared storage - */ on_shared_storage = virFileIsSharedFS(tpm->data.emulator.source_path, cfg->sharedFilesystems) == 1; - if (incomingMigration && on_shared_storage) - create_storage = false; if (create_storage) { - if (qemuTPMEmulatorCreateStorage(tpm, &created, + if (qemuTPMEmulatorCreateStorage(tpm, + incomingMigration && on_shared_storage, + &created, cfg->swtpm_user, cfg->swtpm_group) < 0) return NULL; run_setup = created; @@ -885,6 +890,9 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm, /* If swtpm supports it and the TPM state is stored on shared storage, * start swtpm with --migration release-lock-outgoing so it can migrate * across shared storage if needed. + * + * Note that if 'created' is true, the location didn't exist so the storage + * is not actually shared. */ QEMU_DOMAIN_TPM_PRIVATE(tpm)->swtpm.can_migrate_shared_storage = false; if (on_shared_storage && @@ -892,13 +900,13 @@ qemuTPMEmulatorBuildCommand(virDomainTPMDef *tpm, virCommandAddArg(cmd, "--migration"); virCommandAddArgFormat(cmd, "release-lock-outgoing%s", - incomingMigration ? ",incoming": ""); + incomingMigration && !created ? ",incoming": ""); QEMU_DOMAIN_TPM_PRIVATE(tpm)->swtpm.can_migrate_shared_storage = true; } else { /* Report an error if there's an incoming migration across shared * storage and swtpm does not support the --migration option. */ - if (incomingMigration && on_shared_storage) { + if (incomingMigration && on_shared_storage && !created) { virReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, _("%1$s (on destination side) does not support the --migration option needed for migration with shared storage"), swtpm); -- 2.52.0

2 3

[PATCH v2] NEWS: Mention the passt hostname and fqdn attributes
by Han Han 08 Dec '25

08 Dec '25

Signed-off-by: Han Han <hhan(a)redhat.com> --- V1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NT3X… NEWS.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 01efe82c97..28641ec1a1 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -217,6 +217,11 @@ v11.8.0 (2025-10-01) On the XML side, the existing ``<acpi>`` element has been extended with a ``nodeset`` attribute to specify the NUMA node affinity of a PCI device. + * qemu: Add support for hostname and FQDN configration of passt backend + + The attributes ``hostname`` and ``fqdn`` for passt backend configure + the guest interface with hostname and FQDN. + * **Improvements** * ch: Events emitting -- 2.52.0

2 1

[PATCH 0/1] qemu: Use pci_bus to identify multi-smmuv3 model
by Nathan Chen 05 Dec '25

05 Dec '25

The previous qemu virt-machine smmuv3 model and the new arm-smmuv3 model cannot both be specified at the same time. When launching a Libvirt VM with a single arm-smmuv3 model denoted by the <pciBus> attribute, qemuBuildMachineCommandLine() still appends the iommu=smmuv3 -machine parameter in addition to the arm-smmuv3 model passed to -device, preventing the VM from booting. Use the presence of a non-negative pci_bus to identify the multi-smmuv3 IOMMU model, instead of the niommus attribute. This allows for specifying a single arm-smmuv3 on the qemu command line, instead of both the virt-machine smmuv3 and arm-smmuv3 being specified at the same time. This patch is available on Github [0]. [0] https://github.com/NathanChenNVIDIA/libvirt/commits/single-smmuv3-12-25/ Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (1): qemu: Use pci_bus to identify multi-smmuv3 model src/qemu/qemu_command.c | 2 +- src/qemu/qemu_postparse.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.43.0

2 5

[PULL 14/14] aspeed: Deprecate the fby35 machine
by Alex Bennée 05 Dec '25

05 Dec '25

From: Cédric Le Goater <clg(a)redhat.com> There are no functional tests for the 'fby35' machine which makes harder to determine when something becomes deprecated or unused. The 'fby35' machine was originally added as an example of a multi-SoC system, with the expectation the models would evolve over time in an heterogeneous system. This hasn't happened and no public firmware is available to boot it. It can be replaced by the 'ast2700fc', another multi-SoC machine based on the newer AST2700 SoCs which are excepted to receive better support in the future. Cc: Peter Delevoryas <peter(a)pjd.dev> Signed-off-by: Cédric Le Goater <clg(a)redhat.com> Message-ID: <20251126102424.927527-1-clg(a)redhat.com> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 9386cffba26..ac31a2bce42 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -308,13 +308,24 @@ I2C devices connected to the board can be defined via the QEMU command line. Arm ``fp5280g2-bmc`` machine (since 10.2) -''''''''''''''''''''''''''''''''''''''''''' +''''''''''''''''''''''''''''''''''''''''' The ``fp5280g2-bmc`` machine does not rely on any specific device models, it can be replaced by the ``ast2500-evb`` machine using the ``fmc-model`` option to specify the flash type. The I2C devices connected to the board can be defined via the QEMU command line. +Arm ``fby35`` machine (since 10.2) +'''''''''''''''''''''''''''''''''' + +The ``fby35`` machine was originally added as an example of a +multi-SoC system, with the expectation the models would evolve over +time in an heterogeneous system. This hasn't happened and no public +firmware is available to boot it. It can be replaced by the +``ast2700fc``, another multi-SoC machine based on the newer AST2700 +SoCs which are excepted to receive better support in the future. + + RISC-V default machine option (since 10.0) '''''''''''''''''''''''''''''''''''''''''' diff --git a/hw/arm/fby35.c b/hw/arm/fby35.c index 70d3a99d79e..e61a6438fef 100644 --- a/hw/arm/fby35.c +++ b/hw/arm/fby35.c @@ -175,6 +175,7 @@ static void fby35_class_init(ObjectClass *oc, const void *data) MachineClass *mc = MACHINE_CLASS(oc); mc->desc = "Meta Platforms fby35"; + mc->deprecation_reason = "For a multi-soc machine, use 'ast2700fc' instead"; mc->init = fby35_init; mc->no_floppy = 1; mc->no_cdrom = 1; -- 2.47.3

1 0

[PATCH] ci: refresh with 'lcitool manifest'
by Michal Privoznik 03 Dec '25

03 Dec '25

From: Michal Privoznik <mprivozn(a)redhat.com> Update FreeBSD to their new minor versions. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Green pipeline (although it doesn't show cirrus jobs): https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2194225996 There is also FreeBSD 15.0 which was released yesterday. But there are some issues with its availability in cirrus [1] so I'm not updating the majo version, for now. 1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291354 ci/gitlab/builds.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index a98b0d9c46..fe1468ff81 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -515,7 +515,7 @@ x86_64-freebsd-13: allow_failure: exit_codes: 3 variables: - CIRRUS_VM_IMAGE_NAME: freebsd-13-4 + CIRRUS_VM_IMAGE_NAME: freebsd-13-5 CIRRUS_VM_IMAGE_SELECTOR: image_family CIRRUS_VM_INSTANCE_TYPE: freebsd_instance INSTALL_COMMAND: pkg install -y @@ -530,7 +530,7 @@ x86_64-freebsd-14: allow_failure: exit_codes: 3 variables: - CIRRUS_VM_IMAGE_NAME: freebsd-14-2 + CIRRUS_VM_IMAGE_NAME: freebsd-14-3 CIRRUS_VM_IMAGE_SELECTOR: image_family CIRRUS_VM_INSTANCE_TYPE: freebsd_instance INSTALL_COMMAND: pkg install -y -- 2.51.2

2 1

[PATCH] NEWS: Mention the passt hostname and fqdn attributes
by Han Han 03 Dec '25

03 Dec '25

Signed-off-by: Han Han <hhan(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 91ed53ba7e..1b2b8778b1 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -205,6 +205,12 @@ v11.8.0 (2025-10-01) On the XML side, the existing ``<acpi>`` element has been extended with a ``nodeset`` attribute to specify the NUMA node affinity of a PCI device. + * qemu: Add support for hostname and FQDN configration of passt backend + + Implement passt ``--hostname`` and ``--hostname`` options to libvirt via the + interface attributes ``hostname`` and ``fqdn`` of passt backend. They configure + the guest interface with hostname and FQDN. + * **Improvements** * ch: Events emitting -- 2.52.0

2 2

[RFC v3 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 02 Dec '25

02 Dec '25

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secrets.conf configuration file and parse it secret: Add encryptionSchemeType attribute to store ciphers secret: Add functionality to load and save secrets in encrypted format include/libvirt/libvirt-secret.h | 20 +++ libvirt.spec.in | 7 + po/POTFILES | 1 + src/conf/meson.build | 1 + src/conf/secret_conf.h | 1 + src/conf/secret_config.c | 177 ++++++++++++++++++++++++ src/conf/secret_config.h | 38 +++++ src/conf/virsecretobj.c | 177 ++++++++++++++++++------ src/conf/virsecretobj.h | 13 +- src/libvirt_private.syms | 3 + src/meson.build | 1 + src/secret/libvirt_secrets.aug | 40 ++++++ src/secret/meson.build | 42 ++++++ src/secret/secret-init-encryption.in | 10 ++ src/secret/secret_driver.c | 27 +++- src/secret/secrets.conf.in | 12 ++ src/secret/test_libvirt_secrets.aug.in | 6 + src/secret/virtsecretd.service.extra.in | 8 ++ src/util/vircrypto.c | 126 ++++++++++++++++- src/util/vircrypto.h | 8 ++ src/util/virsecret.c | 4 + src/util/virsecret.h | 1 + tests/vircryptotest.c | 65 +++++++++ 23 files changed, 735 insertions(+), 53 deletions(-) create mode 100644 src/conf/secret_config.c create mode 100644 src/conf/secret_config.h create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret-init-encryption.in create mode 100644 src/secret/secrets.conf.in create mode 100644 src/secret/test_libvirt_secrets.aug.in -- 2.51.1

3 21

[PATCH 0/8] Avoid changing const string via strchr() and friends
by Michal Privoznik 02 Dec '25

02 Dec '25

This stems from the discussion here: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/HVMC… Green pipeline here: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/2183169334 Michal Prívozník (8): vircommand: Update documentation to virCommandSetDryRun() virstringtest: Introduce a test for virSkipSpacesBackwards() virfirewalltest: Introduce testIPtablesSetupPrivateChains() virSkipSpacesBackwards: Turn @endp into const iptablesPrivateChainCreate: Rename @tmp variable iptablesPrivateChainCreate: Switch to STRSKIP() iptablesPrivateChainCreate: Avoid modifying const string lib: Avoid changing const strings via strchr() and friends src/interface/interface_backend_udev.c | 2 +- src/libxl/xen_common.c | 10 +- src/libxl/xen_xm.c | 10 +- src/network/meson.build | 1 + src/network/network_iptables.c | 33 ++++--- src/node_device/node_device_udev.c | 2 +- src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/qemu/qemu_monitor_json.c | 2 +- src/qemu/qemu_nbdkit.c | 2 +- src/rpc/virnetsshsession.c | 5 +- src/storage/storage_util.c | 2 +- src/storage_file/storage_source.c | 4 +- src/util/vircgroup.c | 2 +- src/util/vircommand.c | 10 +- src/util/virfile.c | 2 +- src/util/virstoragefile.c | 4 +- src/util/virstring.c | 20 ++-- src/util/virstring.h | 2 +- src/util/virsysinfo.c | 22 ++--- src/util/virxml.c | 3 +- src/vmware/vmware_conf.c | 2 +- tests/meson.build | 9 +- tests/virfirewalltest.c | 111 ++++++++++++++++++++++ tests/virstringtest.c | 48 ++++++++++ tools/vsh.c | 6 +- 25 files changed, 252 insertions(+), 66 deletions(-) -- 2.51.2

3 11

[RFC PATCH v3 0/4] qemu: Implement support for EGM
by Nathan Chen 01 Dec '25

01 Dec '25

The Grace SOC introduces Extended GPU Memory (EGM) [3], a feature that enables GPUs to efficiently access system memory within and across nodes. This patch series adds support for virtualizing EGM (vEGM) in libvirt, allowing VMs to utilize dedicated EGM memory regions through ACPI. This patch series is a follow-up RFC to the second EGM RFC series [0], to gather feedback from the libvirt community on the overall approach and implementation details. While kernel EGM driver support and QEMU acpi-egm-memory device support are not yet upstream, reference implementations are available [1][2] to enable testing and validation of the libvirt integration. Any community feedback is appreciated. Background and Use Cases ========================= EGM allows host memory to be partitioned into two regions: 1. Standard memory for Host OS usage 2. EGM region assigned to VMs as their system memory This technology enables various high-performance computing scenarios [3]: - Large memory pools for AI/ML workloads - High-performance computing applications - Memory extension for systems with limited main memory - GPU-accelerated workloads requiring large addressable memory Implementation Overview ======================= This series adds a new memory device model VIR_DOMAIN_MEMORY_MODEL_EGM with 'path' source attribute and 'pciDev' target attribute to denote host EGM device backing path and PCI device alias to associate the vEGM with, respectively. For instance, given the XML stanzas below: <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev0</pciDev> </target> </memory> <memory model='egm' access='shared'> <source> <path>/dev/egm5</path> </source> <target> <size unit='KiB'>8388608</size> <node>1</node> <pciDev>ua-hostdev1</pciDev> </target> </memory> The corresponding qemu command line will include the following arguments: -object '{"qom-type":"memory-backend-file","id":"memegm0","mem-path":"/dev/egm4","share":true,"prealloc":true,"size":8589934592}' \ -object acpi-egm-memory,id=egm0,pci-dev=ua-hostdev0,node=0 \ -object '{"qom-type":"memory-backend-file","id":"memegm1","mem-path":"/dev/egm5","share":true,"prealloc":true,"size":8589934592}' \ -object acpi-egm-memory,id=egm1,pci-dev=ua-hostdev1,node=1 \ -numa node,nodeid=0,cpus=0-1,memdev=memegm4 \ -numa node,nodeid=1,cpus=2-3,memdev=memegm5 \ For a system where multiple GPUs are associated with a single host socket/NUMA node/EGM chardev, we consolidate the memory backing into a single memory-backend-file object per host EGM chardev. For instance, given the XML stanzas below: <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev0</pciDev> </target> </memory> <memory model='egm' access='shared'> <source> <path>/dev/egm4</path> </source> <target> <size unit='KiB'>8388608</size> <node>0</node> <pciDev>ua-hostdev1</pciDev> </target> </memory> The corresponding qemu command line will include the following arguments: -object '{"qom-type":"memory-backend-file","id":"memegm0","mem-path":"/dev/egm4","share":true,"prealloc":true,"size":17179869184}' \ -object acpi-egm-memory,id=egm0,pci-dev=ua-hostdev0,node=0 \ -object acpi-egm-memory,id=egm1,pci-dev=ua-hostdev1,node=0 \ -numa node,nodeid=0,cpus=0-4,memdev=memegm0 \ Changes from RFCv2: - Decouple host EGM chardev name from guest EGM ID - Consolidate all acpi-egm-memory objects' memory into a single memory-backend-file per EGM chardev specified. Changes from RFCv1: - Use existing memory device infrastructure to represent EGM configuration - Added support for multiple EGM devices This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/egm-11-24-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/6RU7… [1] https://github.com/ianm-nv/qemu/tree/6.8_ghvirt_egm_may2025 [2] https://github.com/NVIDIA/QEMU/commit/32db1b74fb99c0571724c7e69485e89098c14… [3] https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architectur… Ian May (1): tests: Add qemuxmlconftest for ACPI EGM memory device Nathan Chen (3): conf: Support EGM memory device model qemu: Add cgroup, namespace, and seclabel setup for EGM memory device model qemu: Add qemu CLI support for EGM docs/formatdomain.rst | 18 +- src/conf/domain_conf.c | 34 +++- src/conf/domain_conf.h | 7 + src/conf/domain_postparse.c | 6 +- src/conf/domain_validate.c | 15 ++ src/conf/schemas/domaincommon.rng | 6 + src/qemu/qemu_alias.c | 7 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 10 ++ src/qemu/qemu_command.c | 158 ++++++++++++++++-- src/qemu/qemu_domain.c | 15 +- src/qemu/qemu_domain_address.c | 3 + src/qemu/qemu_driver.c | 1 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_monitor_json.c | 1 + src/qemu/qemu_namespace.c | 3 + src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_process.c | 2 + src/qemu/qemu_validate.c | 6 + src/security/apparmor/usr.sbin.libvirtd.in | 3 + src/security/security_apparmor.c | 2 + src/security/security_dac.c | 8 + src/security/security_selinux.c | 6 + src/security/virt-aa-helper.c | 4 + src/util/virfile.h | 2 +- tests/meson.build | 1 + tests/qemuegmmock.c | 67 ++++++++ .../acpi-egm-memory.aarch64-latest.args | 47 ++++++ .../acpi-egm-memory.aarch64-latest.xml | 124 ++++++++++++++ tests/qemuxmlconfdata/acpi-egm-memory.xml | 124 ++++++++++++++ tests/qemuxmlconftest.c | 8 +- 32 files changed, 672 insertions(+), 21 deletions(-) create mode 100644 tests/qemuegmmock.c create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.xml -- 2.43.0

2 8

[PATCH 0/3] Fix VMX-* feature detection from MSR
by Hector Cao 01 Dec '25

01 Dec '25

Currently, libvirt is unable to detect the CPU model of recent Intel CPUs (like Granite Rapids) with VMX-* features specified in the MSRs (Model Specific Registers). This is due to the wrong parsing of these VMX-* features from the MSR values. This series of 3 commits allow to fix the MSR VMX-* feature detection. This has been tested successfully on a platform equipped with Intel Granite Rapids CPU. Hector Cao (3): cpu_map: fix sync script to extract correctly vmx-* features cpu_map: update vmx-* features cputest : fix test failures due to VMX-* feature update src/cpu_map/sync_qemu_features_i386.py | 19 +++ src/cpu_map/x86_features.xml | 136 +++++++++--------- .../x86_64-cpuid-Atom-P5362-2-enabled.xml | 10 +- .../x86_64-cpuid-Atom-P5362-enabled.xml | 10 +- .../x86_64-cpuid-Cooperlake-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-1270P-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-1365U-enabled.xml | 10 +- .../x86_64-cpuid-Core-i7-8550U-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6731E-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6788P-disabled.xml | 1 + .../x86_64-cpuid-Xeon-6788P-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-6788P-guest.xml | 17 ++- .../x86_64-cpuid-Xeon-6788P-host.xml | 17 ++- ...x86_64-cpuid-Xeon-Bronze-3408U-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-E3-1270-v5-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-Gold-6152-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-Gold-6530-enabled.xml | 10 +- ...86_64-cpuid-Xeon-Platinum-9242-enabled.xml | 10 +- ...x86_64-cpuid-Xeon-Silver-4214R-enabled.xml | 10 +- .../x86_64-cpuid-Xeon-w7-3465X-enabled.xml | 10 +- 20 files changed, 181 insertions(+), 159 deletions(-) -- 2.45.2

3 8