Re: [PATCH v2] i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 14 Aug 2024 00:39:57 +0800
Xiaoyao Li <xiaoyao.li@intel.com> wrote:

> On 8/13/2024 10:51 PM, Xiaoyao Li wrote:
> > On 8/13/2024 5:27 PM, Igor Mammedov wrote:  
> >> On Mon, 12 Aug 2024 23:31:45 -0400
> >> Xiaoyao Li <xiaoyao.li@intel.com> wrote:
> >>  
> >>> Currently, QEMU exposes CPUID 0x1f to guest only when necessary, i.e.,
> >>> when topology level that cannot be enumerated by leaf 0xB, e.g., die or
> >>> module level, are configured for the guest, e.g., -smp xx,dies=2.
> >>>
> >>> However, 1) TDX architecture forces to require CPUID 0x1f to 
> >>> configure CPU
> >>> topology. and 2) There is a bug in Windows that Windows 10/11 expects 
> >>> valid
> >>> 0x1f leafs when the maximum basic leaf > 0x1f[1].  
> >>   1. will it boot if you use older cpu model?  
> > 
> > It can boot with any cpu model that has .level < 0x1f.  
> 
> I realize just now that we don't need to introduce "x-cpuid-1f" as the 
> workaround for buggy windows. We can always workaround it by limiting 
> the maximum basic CPUID leaf to less than 0x1f, i.e., -cpu xxx,level=0x1e

I'd suggest to add this to change log into 'known issues' section.
(I mean Windows bug symptoms and suggested workaround)  

> 
> I think we can ignore this patch for now. I will re-submit it with TDX 
> enabling series, and with "x-cpuid-1f" interface removed.
> 
> >>   2. how user would know that this option would be needed?  
> > 
> > Honestly, I don't have an answer for it.
> > 
> > I'm not sure if it is the duty of QEMU to identify this case and print 
> > some hint to user. It's the bug of Windows, maybe Mircosoft should put 
> > something in their known bugs list for users?
I guess you've answered your own question alredy we have a workaround
and there is not need for yet another option that user won't know how to use.

As for configuring workaround, it's upto upper layers which know what OS
would be running in VM.