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.mis...@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://github.com/qemu/qemu/blob/58ee924b97d1c0898555647a31820c5a20d55a73/target/i386/kvm/kvm.c#L1834>. > As per expectation(also mentioned in > https://cdrdv2-public.intel.com/775917/intel-64-architecture-processor-topology-enumeration.pdf) > 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. Thanks, Zhao
