qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC 06/10] i386/cpu: Introduce enable_cpuid_0x1f to force exposing


From: Xiaoyao Li
Subject: Re: [RFC 06/10] i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f
Date: Thu, 15 May 2025 14:43:27 +0800
User-agent: Mozilla Thunderbird

On 5/14/2025 11:23 PM, Zhao Liu wrote:
Hi Igor, thanks for your review!

On Tue, May 13, 2025 at 02:45:15PM +0200, Igor Mammedov wrote:
Date: Tue, 13 May 2025 14:45:15 +0200
From: Igor Mammedov <imammedo@redhat.com>
Subject: Re: [RFC 06/10] i386/cpu: Introduce enable_cpuid_0x1f to force
  exposing CPUID 0x1f
X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-redhat-linux-gnu)

On Wed, 23 Apr 2025 19:46:58 +0800
Zhao Liu <zhao1.liu@intel.com> wrote:

From: Xiaoyao Li <xiaoyao.li@intel.com>

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, TDX architecture forces to require CPUID 0x1f to configure CPU
topology.

Introduce a bool flag, enable_cpuid_0x1f, in CPU for the case that
requires CPUID leaf 0x1f to be exposed to guest.

Introduce a new function x86_has_cpuid_0x1f(), which is the warpper of
cpu->enable_cpuid_0x1f and x86_has_extended_topo() to check if it needs
to enable cpuid leaf 0x1f for the guest.

that reminds me about recent attempt to remove enable_cpuid_0xb,

So is enable_cpuid_0x1f inteded to be used by external users or
it's internal only knob for TDX sake?

TDX needs this and I also try to apply this to named CPU models. For
max/host CPUs, there are no explicit use cases. I think it's enough to
make named CPU models have 0x1f.

Then this should be only used internally.

I'd push for it being marked as internal|unstable with the means
we currently have (i.e. adding 'x-' prefix)

Sure, 'x-' is good. (If there is the internal property in the future,
I can also convert this unsatble property into internal one.)

This patch is picked from the TDX series, and in this patch Xiaoyao
doesn't make 0x1f enabling as property. In the next patch (RFC patch 7),
I add the "cpuid-0x1f" property. I'll rename that property as
"x-cpuid-0x1f".

and also enable_ is not right here, the leaf is enabled when
topology requires it.
perhaps s/enable_/force_/

Thanks, I agree force_cpuid_0x1f is a better name.

@Xiaoyao, do you agree with this idea?

But probably TDX won't have v10 though, I can rename the field in my v2
after TDX.

I'm OK with it.

The TDX series won't be merged by Paolo soon. It has to be after the KVM part being in linux v6.16-rc1, i.e., about one month later.

And there are rebase conflicts when I rebase the TDX-QEMU series against upstream QEMU master daily. It seems to have a newer version of TDX-QEMU when it's going to be picked up by Paolo for Paolo's convenience. If a v10 needed, I can rename in it.

Let's see how it goes.

Regards,
Zhao





reply via email to

[Prev in Thread] Current Thread [Next in Thread]