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@xxxxxxxxx>
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@xxxxxxxxx>
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.
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.
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.
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.
SDM keeps cpuid 0xb is for backwards compatibility.
Regards,
Zhao
