All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Shivansh Dhiman <shivansh.dhiman@amd.com>
Cc: pbonzini@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org,
	qemu-devel@nongnu.org, seanjc@google.com, santosh.shukla@amd.com,
	nikunj.dadhania@amd.com, ravi.bangoria@amd.com,
	babu.moger@amd.com
Subject: Re: [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026
Date: Mon, 12 Jan 2026 15:57:27 +0800	[thread overview]
Message-ID: <aWSpZxg7kKrdBifu@intel.com> (raw)
In-Reply-To: <8ef42171-5473-449f-bd72-e9874fa6f7f1@amd.com>

> On 07-01-2026 13:17, Zhao Liu wrote:
> > On Fri, Nov 21, 2025 at 08:34:49AM +0000, Shivansh Dhiman wrote:
> >> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> >> index b7827e448aa5..01c4da7cf134 100644
> >> --- a/target/i386/cpu.c
> >> +++ b/target/i386/cpu.c
> >> @@ -9158,6 +9158,12 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
> >>          if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_SGX) {
> >>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x12);
> >>          }
> >> +
> >> +        /* Enable CPUID[0x80000026] for AMD Genoa models and above */
> >> +        if (cpu->force_cpuid_0x80000026 ||
> >> +            (!xcc->model && x86_is_amd_zen4_or_above(cpu))) {
> > 
> > I understand you want to address max/host CPU case here, but it's still
> > may not guarentee the compatibility with old QEMU PC mahinces, e.g.,
> > boot a old PC machine on v11.0 QEMU, it can still have this leaf.
> 
> Wouldn't initializing x-force-cpuid-0x80000026 default to false prevent this?
> Oh, but, this CPUID can still be enabled on an older machine-type with latest
> QEMU with the existing checks. And probably this could also affect live migration.

Yes, on a zen4 host, booting an older machine with latest QEMU will have
this CPUID leaf.
 
> > So it would be better to add a compat option to disable 0x80000026 for
> > old PC machines by default.
> 
> Does this look fine?
> 
> GlobalProperty pc_compat_10_2[] = {
>     { TYPE_X86_CPU, "x-force-cpuid-0x80000026", "false" },
> };
> const size_t pc_compat_10_2_len = G_N_ELEMENTS(pc_compat_10_2);

It looks fine if we only check "if (cpu->force_cpuid_0x80000026)".

> > If needed, to avoid unnecessarily enabling extended CPU topology, I think
> > it's possible to implement a check similar to x86_has_cpuid_0x1f().
> 
> Do you mean something like this? I avoided it initially because it is
> functionally same as current one, and a bit lengthy.

Sorry for confusion. Could we get rid of model check
(x86_is_amd_zen4_or_above)? and could we do something like 0x1f leaf,

static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
{
    return cpu->force_cpuid_0x1f ||
           x86_has_extended_topo(cpu->env.avail_cpu_topo);
	   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}

similarly, apply x86_has_extended_topo() for AMD CPU as well?

x86_has_extended_topo() also checks "module" level, but I think we could
return error in encode_topo_cpuid80000026() for unsupported "moduel"
level?

Thus, when users explicitly set these levels, the 0x80000026 leaf will be
enabled.

Furthermore, I think it's better that different x86 vendors could adopt
similar behavior for these extended topology levels, especially since
they are all all configured through a unified "-smp" interface.

Thanks,
Zhao


  reply	other threads:[~2026-01-12  7:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21  8:34 [PATCH 0/5] i386: Add support for CPUID 0x80000026 and Bus Lock Detect Shivansh Dhiman
2025-11-21  8:34 ` [PATCH 1/5] i386: Implement CPUID 0x80000026 Shivansh Dhiman
2026-01-07  7:25   ` Zhao Liu
2026-01-08 10:33     ` Shivansh Dhiman
2026-01-09  9:03       ` Zhao Liu
2026-01-09 11:41         ` Shivansh Dhiman
2026-01-12  8:01           ` Zhao Liu
2026-02-04  6:43             ` Shivansh Dhiman
2025-11-21  8:34 ` [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026 Shivansh Dhiman
2026-01-07  7:47   ` Zhao Liu
2026-01-09  9:00     ` Shivansh Dhiman
2026-01-12  7:57       ` Zhao Liu [this message]
2026-02-04  6:42         ` Shivansh Dhiman
2025-11-21  8:34 ` [PATCH 3/5] i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU Shivansh Dhiman
2026-01-07  7:47   ` Zhao Liu
2025-11-21  8:34 ` [PATCH 4/5] i386: Add Bus Lock Detect support Shivansh Dhiman
2026-02-04  9:02   ` Shivansh Dhiman
2025-11-21  8:34 ` [PATCH 5/5] i386: Add Bus Lock Detect support for EPYC-Turin-v2 model Shivansh Dhiman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWSpZxg7kKrdBifu@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=babu.moger@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nikunj.dadhania@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ravi.bangoria@amd.com \
    --cc=santosh.shukla@amd.com \
    --cc=seanjc@google.com \
    --cc=shivansh.dhiman@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.