Hello, I'm unable to make virsh capabilities to detect the right CPU model on an Intel Granite Rapids platform. I would expect the get the CPU model defined in one of the src/cpu_map/x86_GraniteRapids*.xml files. The cause of the wrong detection is the fact that some vmx-* are not correctly detected and considered missing on this platform. When I take a look at the src/cpu_map/x86_features.xml file, I think that some of the vmx-* are wrongly defined. Taking as an example the vmx-apicv-xapic feature, it is defined as the first bit in the EAX register when we read the MSR 0x0000048b . But in Intel specification, this feature is represented as the first bit in the EDX register (32 higher bits). You can find in this submission the patch that fixes this issue, and this for all the affected MSRs. I tested this fix on my Granite Rapids platform and the CPU model is now correctly detected. Hector Cao (1): cpu_map: fix vmx-* features wrong bitmaps src/cpu_map/x86_features.xml | 136 +++++++++++++++++------------------ 1 file changed, 68 insertions(+), 68 deletions(-) -- 2.45.2
I just realized that I should not modify the x86_features.xml file directly. I have to fix this issue elsewhere, probably in the sync_qemu_features_i386.py script or in the libvirt code that reads the MSRs registers. QEMU specifies vmx-apicv-xapic as 1st bit of the register 0x48B (IA32_VMX_PROCBASED_CTLS2) but has the login to interpret this bit position correctly in the register raw value. Libvirt does not have this login and by consequence, does not get the right bit value. I would appreciate some feedback on how we can best tackle this. On Sat, May 31, 2025 at 12:31 AM Hector Cao <hector.cao@canonical.com> wrote: > Hello, > > I'm unable to make virsh capabilities to detect the right CPU model > on an Intel Granite Rapids platform. I would expect the get the > CPU model defined in one of the src/cpu_map/x86_GraniteRapids*.xml > files. > > The cause of the wrong detection is the fact that some vmx-* are > not correctly detected and considered missing on this platform. > > When I take a look at the src/cpu_map/x86_features.xml file, I > think that some of the vmx-* are wrongly defined. > > Taking as an example the vmx-apicv-xapic feature, it is defined as > the first bit in the EAX register when we read the MSR 0x0000048b . > But in Intel specification, this feature is represented as the first > bit in the EDX register (32 higher bits). > > You can find in this submission the patch that fixes this issue, > and this for all the affected MSRs. > > I tested this fix on my Granite Rapids platform and the CPU model > is now correctly detected. > > Hector Cao (1): > cpu_map: fix vmx-* features wrong bitmaps > > src/cpu_map/x86_features.xml | 136 +++++++++++++++++------------------ > 1 file changed, 68 insertions(+), 68 deletions(-) > > -- > 2.45.2 > > -- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
Hello,
A friendly ping,
To fix this issue, I would like to propose this solution.
Here is the draft patch, I can submit a proper one in a separate mail if we
can reach an agreement
on this solution.
Thanks !
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 0f7eb8f48b..570160c18f 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2922,6 +2922,16 @@ virCPUx86GetHost(virCPUDef *cpu,
},
};
+ if ((item.data.msr.index == 0x48B)
+ || (item.data.msr.index == 0x48D)
+ || (item.data.msr.index == 0x48E)
+ || (item.data.msr.index == 0x48F)
+ || (item.data.msr.index == 0x490)
+ ) {
+ item.data.msr.eax = item.data.msr.edx & ~item.data.msr.eax;
+ item.data.msr.edx = 0;
+ }
+
virCPUx86DataAdd(cpuData, &item);
}
}
On Sun, Jun 1, 2025 at 11:01 PM Hector Cao <hector.cao@canonical.com> wrote:
> I just realized that I should not modify the x86_features.xml file
> directly.
>
> I have to fix this issue elsewhere, probably in
> the sync_qemu_features_i386.py
> script or in the libvirt code that reads the MSRs registers.
>
> QEMU specifies vmx-apicv-xapic as 1st bit of the register 0x48B
> (IA32_VMX_PROCBASED_CTLS2)
> but has the login to interpret this bit position correctly in the register
> raw value.
> Libvirt does not have this login and by consequence, does not get the
> right bit value.
>
> I would appreciate some feedback on how we can best tackle this.
>
> On Sat, May 31, 2025 at 12:31 AM Hector Cao <hector.cao@canonical.com>
> wrote:
>
>> Hello,
>>
>> I'm unable to make virsh capabilities to detect the right CPU model
>> on an Intel Granite Rapids platform. I would expect the get the
>> CPU model defined in one of the src/cpu_map/x86_GraniteRapids*.xml
>> files.
>>
>> The cause of the wrong detection is the fact that some vmx-* are
>> not correctly detected and considered missing on this platform.
>>
>> When I take a look at the src/cpu_map/x86_features.xml file, I
>> think that some of the vmx-* are wrongly defined.
>>
>> Taking as an example the vmx-apicv-xapic feature, it is defined as
>> the first bit in the EAX register when we read the MSR 0x0000048b .
>> But in Intel specification, this feature is represented as the first
>> bit in the EDX register (32 higher bits).
>>
>> You can find in this submission the patch that fixes this issue,
>> and this for all the affected MSRs.
>>
>> I tested this fix on my Granite Rapids platform and the CPU model
>> is now correctly detected.
>>
>> Hector Cao (1):
>> cpu_map: fix vmx-* features wrong bitmaps
>>
>> src/cpu_map/x86_features.xml | 136 +++++++++++++++++------------------
>> 1 file changed, 68 insertions(+), 68 deletions(-)
>>
>> --
>> 2.45.2
>>
>>
>
> --
> Hector CAO
> Software Engineer – Partner Engineering Team
> hector.cao@canonical.com
> https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
> <https://launchpad.net/~hectorcao>
>
> <https://launchpad.net/~hectorcao>
>
--
Hector CAO
Software Engineer – Partner Engineering Team
hector.cao@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>
<https://launchpad.net/~hectorcao>
On Mon, Jun 16, 2025 at 01:46:59 +0200, Hector Cao wrote:
> Hello,
>
> A friendly ping,
>
> To fix this issue, I would like to propose this solution.
> Here is the draft patch, I can submit a proper one in a separate mail if we
> can reach an agreement
> on this solution.
>
> Thanks !
>
> diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
> index 0f7eb8f48b..570160c18f 100644
> --- a/src/cpu/cpu_x86.c
> +++ b/src/cpu/cpu_x86.c
> @@ -2922,6 +2922,16 @@ virCPUx86GetHost(virCPUDef *cpu,
> },
> };
>
> + if ((item.data.msr.index == 0x48B)
> + || (item.data.msr.index == 0x48D)
> + || (item.data.msr.index == 0x48E)
> + || (item.data.msr.index == 0x48F)
> + || (item.data.msr.index == 0x490)
> + ) {
> + item.data.msr.eax = item.data.msr.edx & ~item.data.msr.eax;
> + item.data.msr.edx = 0;
> + }
> +
> virCPUx86DataAdd(cpuData, &item);
> }
> }
Hi, I apologize for a late response. I need to study the details to
understand what actually is the problem and mainly the consequences of
changing it and the best place for such a change. In general, the
conversion from raw bits to names and back is only limited to a single
host and I think there is just one place where the actual values matter
(more than being distinct) and the result is not used for anything
serious. Thus we should be able to change the values in out CPU map
without introducing real issues, but I need to think about it more.
Jirka
© 2016 - 2025 Red Hat, Inc.