Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F]

[Zhao Liu <zhao1.liu@linux.intel.com>]

Hi Xiaoyao,

On Mon, Jan 15, 2024 at 03:16:43PM +0800, Xiaoyao Li wrote:
> Date: Mon, 15 Jan 2024 15:16:43 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F]
> 
> On 1/15/2024 2:35 PM, Zhao Liu wrote:
> > On Mon, Jan 15, 2024 at 02:11:17PM +0800, Xiaoyao Li wrote:
> > > Date: Mon, 15 Jan 2024 14:11:17 +0800
> > > From: Xiaoyao Li <xiaoyao.li@intel.com>
> > > Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F]
> > > 
> > > On 1/15/2024 2:12 PM, Zhao Liu wrote:
> > > > Hi Xiaoyao,
> > > > 
> > > > On Mon, Jan 15, 2024 at 12:34:12PM +0800, Xiaoyao Li wrote:
> > > > > Date: Mon, 15 Jan 2024 12:34:12 +0800
> > > > > From: Xiaoyao Li <xiaoyao.li@intel.com>
> > > > > Subject: Re: [PATCH v7 08/16] i386: Expose module level in CPUID[0x1F]
> > > > > 
> > > > > > Yes, I think it's time to move to default 0x1f.
> > > > > 
> > > > > we don't need to do so until it's necessary.
> > > > 
> > > > Recent and future machines all support 0x1f, and at least SDM has
> > > > emphasized the preferred use of 0x1f.
> > > 
> > > The preference is the guideline for software e.g., OS. QEMU doesn't need to
> > > emulate cpuid leaf 0x1f to guest if there is only smt and core level.
> > 
> > Please, QEMU is emulating hardware not writing software.
> 
> what I want to conveyed was that, SDM is teaching software how to probe the
> cpu topology, not suggesting VMM how to advertise cpu topology to guest.
> 

This reflects the hardware's behavioral tendency. Additionally, due to SDM
related suggestion about 0x1f preference, lots of new software may rely on
0x1f, making 0x1f as the default enabling leaf helps to enhance Guest
compatibility.

> 
> > Is there any
> > reason why we shouldn't emulate new and generic hardware behaviors and
> > stick with the old ones?
> 
> I didn't say we shouldn't, but we don't need to do it if it's unnecessary.

Probably never going to deprecate 0x0b, and 0x1f is in fact replacing 0x0b,
kind of like a timing issue, when should 0x1f be enabled by default?

Maybe for some new CPU models or -host, we can start making it as default.
This eliminates the difference in the CPU topology enumeration interface
between Host and Guest. What do you think?

> 
> if cpuid 0x1f is advertised to guest by default, it will also introduce the
> inconsistence. Old product doesn't have cpuid 0x1f, but using QEMU to
> emualte an old product, it has.

Yes, this is the similar case as 0x0b. Old machine doens't has 0x0b. And
QEMU uses cpuid-0xb option to resolve compatibility issue.

> 
> sure we can have code to fix it, that only expose 0x1f to new enough cpu
> model. But it just make thing complicated.
> 
> > > because in this case, they are exactly the same in leaf 0xb and 0x1f. we don't
> > > need to bother advertising the duplicate data.
> > 
> > You can't "define" the same 0x0b and 0x1f as duplicates. SDM doesn't
> > have such the definition.
> 
> for QEMU, they are duplicate data that need to be maintained and need to be
> passed to KVM by KVM_SET_CPUID. For guest, it's also unnecessary, because it
> doesn't provide any additional information with cpuid leaf 1f.

I understand your concerns. The benefit is to follow the behavior of the
new hardware and spec recommendations, on new machines people are going
to be more accustomed to using 0x1f to get topology, and VMs on new
machines that don't have 0x1f will tend to get confused.

I could start by having a look at if we could synchronize Host in -host
to enable 0x1f. If there isn't too much block, -host is an acceptable
starting point, after all, there are no additional compatibility issues
for this case. ;-)

Thanks,
Zhao

> 
> SDM keeps cpuid 0xb is for backwards compatibility.
>