** Description changed: libvirt is unable to detect correctly Intel Granite Rapids processors vmx-* features - Old bug report description ---- [ Impact ] - Libvirt is missing support for Intel Granite Rapids processors. + Libvirt was not detecting Intel Granite Rapids processors correctly. + It was found that this is due to registers for that to not be correct + in the cpu information, affecting even other CPU types. - This should be fixed as a part of hardware enablement. + Fixing that info in the data files allows libvirt to detect cpu features + for recent Intel CPUs correctly, [ Test Plan ] - To test the fix, an Intel Granite Rapids system must be used. + To test the fix in general any recent x86 system can be used, to see the + features of Intel Granite Rapids where it was originally found a system + with such a CPU must be used. Install libvirt with: $ sudo apt install qemu-kvm libvirt-daemon-system Then check the processor identification with virsh: + With the fix it should detect features on such CPUs better, compare the + output of + $ virsh capabilities - It should respond with the model GraniteRapids in the format: - - <capabilities> - - <host> - <uuid>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</uuid> - <cpu> - <arch>x86_64</arch> - <model>GraniteRapids</model> - <vendor>Intel</vendor> - ... + Depending on your chip e.g. the reported CPU type name will change to be + closer to the correct type. [ Where problems could occur ] - Since the change comes in as one commit and well isolated from the rest - of the libvirt source tree. I don't expect places where problems could - occur because of the intruduction of this change. + Since the change comes in as one single commit and is gladly well + isolated from the rest of the libvirt source tree. I don't expect + problems in other areas of the code, so what we need to look out for is + CPU type and feature detection behavior (but only that). [ Other Info ] The issue is fixed through a patch that adds necessary CPU features and definitions. For the majority of use cases libvirt, is used with Qemu backend (other backends are KVM and LXC), this libvirt capability requires Qemu to have the same capability. The granite rapids support has been introduced to Qemu upstream in the commit: 6d5e9694e : target/i386: Add new CPU model GraniteRapids And this change has been released in Qemu upstream v8.1.0 and is available in Oracular (1:9.0.2+ds-4ubuntu5) and Noble (1:8.2.2+ds-0ubuntu1.3) ------------- [Description] Add Granite Rapids CPU model feature map to libvirt, depends on QEMU support. [Hardware Information] Architecture: Intel / AMD (x86_64) Platform(s) Granite Rapids Date HW is expected at Canonical: Component(s): LibvirtVirtualization [Software Information] Target Version: 24.04 Target Kernel: libvirt-v10.0.0 Commit IDs: 03852c85af3c531d1459573341537d1cc8e4b3c6 cpu_map: Add GraniteRapids CPU model External Links: https://gitlab.com/libvirt/libvirt [Business Justification] [Testing guidance] [External ID]
** Description changed: libvirt is unable to detect correctly Intel Granite Rapids processors vmx-* features Old bug report description ---- [ Impact ] Libvirt was not detecting Intel Granite Rapids processors correctly. It was found that this is due to registers for that to not be correct in the cpu information, affecting even other CPU types. Fixing that info in the data files allows libvirt to detect cpu features for recent Intel CPUs correctly, [ Test Plan ] To test the fix in general any recent x86 system can be used, to see the features of Intel Granite Rapids where it was originally found a system with such a CPU must be used. Install libvirt with: $ sudo apt install qemu-kvm libvirt-daemon-system Then check the processor identification with virsh: With the fix it should detect features on such CPUs better, compare the output of $ virsh capabilities Depending on your chip e.g. the reported CPU type name will change to be - closer to the correct type. + closer to the correct type. The exact behavior depends on the CPU, the + verification should present a before/after output of such an example. [ Where problems could occur ] Since the change comes in as one single commit and is gladly well isolated from the rest of the libvirt source tree. I don't expect problems in other areas of the code, so what we need to look out for is CPU type and feature detection behavior (but only that). [ Other Info ] The issue is fixed through a patch that adds necessary CPU features and definitions. For the majority of use cases libvirt, is used with Qemu backend (other backends are KVM and LXC), this libvirt capability requires Qemu to have the same capability. The granite rapids support has been introduced to Qemu upstream in the commit: 6d5e9694e : target/i386: Add new CPU model GraniteRapids And this change has been released in Qemu upstream v8.1.0 and is available in Oracular (1:9.0.2+ds-4ubuntu5) and Noble (1:8.2.2+ds-0ubuntu1.3) ------------- [Description] Add Granite Rapids CPU model feature map to libvirt, depends on QEMU support. [Hardware Information] Architecture: Intel / AMD (x86_64) Platform(s) Granite Rapids Date HW is expected at Canonical: Component(s): LibvirtVirtualization [Software Information] Target Version: 24.04 Target Kernel: libvirt-v10.0.0 Commit IDs: 03852c85af3c531d1459573341537d1cc8e4b3c6 cpu_map: Add GraniteRapids CPU model External Links: https://gitlab.com/libvirt/libvirt [Business Justification] [Testing guidance] [External ID] -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2083293 Title: [SRU] [GNR] Virt-Libvirt: Add platform support to libvirt To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/2083293/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
