!-------------------------------------------------------------------|
CAUTION: External Email
|-------------------------------------------------------------------!
Hi Manish,
(+Paolo and Daniel)
On Thu, Jul 18, 2024 at 11:44:28AM +0000, Manish Mishra wrote:
> Date: Thu, 18 Jul 2024 11:44:28 +0000
> From: Manish Mishra <manish.mishra@nutanix.com>
> Subject: Windows 10 and 11 VMs fails to boot with SapphireRapids CPU
> definition
>
> Hi Everyone,
>
> We are facing issues booting windows VMs with SapphireRapids CPU definition. This is happening in case we have multiple cores per vcpu set and the VM is a UEFI, secure boot and credential guard enabled. Till now we have observed this issue on windows 10 and
11.
>
>
>
> We did some triaging around this. SapphireRapids CPU definition has raised cpuid_level to 0x20. This includes leaf V2 extended topology (0x1f). QEMU returns all zeros in case !x86_has_extended_topo()<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_qemu_qemu_blob_58ee924b97d1c0898555647a31820c5a20d55a73_target_i386_kvm_kvm.c-23L1834&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=93ULgJDhgIvMy2Ole06ELBkjaaFZ6Payy6zCm0ZkdJvHXYZkuImyiD0ECiyOOWVw&s=xPOOrTiYmyohulEn3Tl3yv2ea4JKWdU_Q7mEWviDrMk&e=
>. As per expectation(also mentioned in https://urldefense.proofpoint.com/v2/url?u=https-3A__cdrdv2-2Dpublic.intel.com_775917_intel-2D64-2Darchitecture-2Dprocessor-2Dtopology-2Denumeration.pdf&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=93ULgJDhgIvMy2Ole06ELBkjaaFZ6Payy6zCm0ZkdJvHXYZkuImyiD0ECiyOOWVw&s=YYBgZ76FZdCOKQHzmERHS7CXt0DgakkusRqy9tq9WNE&e=
) if guests see this it should fallback to 0x1b. Somehow windows 10 and windows 11 does not work well with this assumption and panics on boot.
>
>
>
> We checked on one of the SapphireRapids node with no multi-die topology; this is how CPUID output looks like. 0x1f output is the same as 0xb.
[snip]
> We tried a workaround having 0x1f output same as 0xb in case !x86_has_extended_topo(), instead of setting all zeros. This seems to work fine. Our understanding is that current QEMU behaviour is not incorrect but still does the above mentioned workaround makes
sense?
The 0x1f was introduced from cascadelake-AP (2nd xeon) with multiple
dies, but cascadelake-SP doesn't has the 0x1f since it has only 1 die.
So from that time, QEMU's 0x1f checks for extended topology level to
determine whether to populate the 0x1f. HMM, currently, for this
all-zero 0x1f, it's valid because x86 (SDM) said "if a value entered
for CPUID.EAX is less than or equal to the maximum input value and the
leaf is not supported on that processor then 0 is returned in all the
registers."
So yes you're right, and it's actually a Windows issue, which should
check 0xb.
And you proposed to populate 0x1f by default even without die/module
should work:
* older software still checks 0xb by default, then the newly added 0x1f
doesn't break anything.
* And software that follow the SDM recommendation to check 0x1f first
by default will also benefit.
No one else has reported problems for old CPUs yet, but CPUs older than
cascadelake should disable configuration of extended topology levels to
avoid 0x1f creating compatibility issues. Of course, the current
workaround doesn't need to take that into account.
> And if we look it is the same as bare-metal so it should not be unreasonable. If so will be happy to send a patch for same.
I think it's worth doing, and I'll help you review.
You may refer to "cpuid-0xb" implementation and add the compat setting
pc_compat_9_0.