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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. Is there any
reason why we shouldn't emulate new and generic hardware behaviors and
stick with the old ones?

> 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.

Regards,
Zhao





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux