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....@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....@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....@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....@canonical.com
https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao
<https://launchpad.net/~hectorcao>
<https://launchpad.net/~hectorcao>
