[RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[Zhao Liu]

Hi all,

(Since patches 1 and 2 involve changes to x86 vendors other than Intel,
I have also cc'd friends from AMD and Zhaoxin.)

These are the ones I was going to clean up a long time ago:
 * Fixup CPUID 0x80000005 & 0x80000006 for Intel (and Zhaoxin now).
 * Add cache model for Intel CPUs.
 * Enable 0x1f CPUID leaf for specific Intel CPUs, which already have
   this leaf on host by default.

Overall, the enhancements to the Intel CPU models are still based on
feedback received over time, for a long time...

I'll introduce my changes one by one in the order of importance as I
see it. (The doc update is missing in this version.)


Intel Cache Model
=================

AMD has supports cache model for a long time. And this feature strats
from the Eduardo's idea [1].

Unfortunately, Intel does not support this, and I have received some
feedback (from Tejus on mail list [2] and kvm forum, and from Jason).

Additionally, after clearly defining the cache topology for QEMU's
cache model, outdated cache models can easily raise more questions. For
example, the default legacy cache model's L3 is per die, but SPR's
real L3 is per socket. Users may question how the L3 topology changes
when multiple dies are created (discussed with Daniel on [3]).

So, in this series, I have added cache models for SRF, GNR, and SPR
(because these are the only machines I can find at the moment :-) ).

Note that the cache models are based on the Scalable Performance (SP)
version, and the Xeon Advanced Performance (AP) version may have
different cache sizes. However, SP is sufficient as the default cache
model baseline. In the future, I will consider adding additional
parameters in "smp-cache" to adjust cache sizes to meet different needs.

[1]: https://lore.kernel.org/qemu-devel/20180320175427.GU3417@localhost.localdomain/
[2]: https://lore.kernel.org/qemu-devel/6766AC1F-96D1-41F0-AAEB-CE4158662A51@nutanix.com/
[3]: https://lore.kernel.org/qemu-devel/ZkTrsDdyGRFzVULG@redhat.com/

0x1f CPUID by default (for some CPUs)
=====================================

Once the cache model can be clearly defined, another issue is the
topology.

Currently, the cache topology is actually tied to the CPU topology.
However, in recent Intel CPUs (from cascadelake-AP - 2nd xeon [4]),
CPU topology information is primarily expressed using the 0x1f leaf.

Due to compatibility issues and historical reasons, the Guest's 0x1f
is not unconditionally exposed.

The discrepancy between having 0x1f on the Host but not on the Guest
does indeed cause problems (Manish mentioned in [5]).

Manish and Xiaoyao (for TDX) both attempted to enable 0x1f by default
for Intel CPUs [6] [7], but following Igor's suggestion, it is more
appropriate to enable it by default only for certain CPU models [8]. 

So, as I update the CPU model at this time, I think it's time to revisit
the community's idea (referencing patch 7, where I "took the liberty" to
merge the property-related work pieces from Manish and Xiaoyao, based on
a TDX patch from Xiaoyao [9]).

I enable the 0x1f leaf for SRF, GNR and SPR by default for better
emulation of real silicons.

[4]: https://lore.kernel.org/qemu-devel/ZpoWskY4XE%2F98jss@intel.com/
[5]: https://lore.kernel.org/qemu-devel/PH0PR02MB738410511BF51B12DB09BE6CF6AC2@PH0PR02MB7384.namprd02.prod.outlook.com/
[6]: https://lore.kernel.org/qemu-devel/20240722101859.47408-1-manish.mishra@nutanix.com/
[7]: https://lore.kernel.org/qemu-devel/20240813033145.279307-1-xiaoyao.li@intel.com/
[8]: https://lore.kernel.org/qemu-devel/20240723170321.0ef780c5@imammedo.users.ipa.redhat.com/
[9]: https://lore.kernel.org/qemu-devel/20250401130205.2198253-34-xiaoyao.li@intel.com/


CPUID 0x80000005 & 0x80000006 Fix
=================================

CPUID[0x80000005] is reserved for Intel, and Intel only supports
CPUID[0x80000006].ECX. And becuase AMD requires lines_per_tag to be not
0, which blocks Intel's new cache model.

Therefore, fix these 2 leaves for Intel (and Zhaoxin - which follows
Intel's SDM).

Thanks and Best Regards,
Zhao
---
Manish Mishra (1):
  i386/cpu: Add a "cpuid-0x1f" property

Xiaoyao Li (1):
  i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f

Zhao Liu (8):
  i386/cpu: Mark CPUID[0x80000005] as reserved for Intel
  i386/cpu: Fix CPUID[0x80000006] for Intel CPU
  i386/cpu: Introduce cache model for SierraForest
  i386/cpu: Introduce cache model for GraniteRapids
  i386/cpu: Introduce cache model for SapphireRapids
  i386/cpu: Enable 0x1f leaf for SierraForest by default
  i386/cpu: Enable 0x1f leaf for GraniteRapids by default
  i386/cpu: Enable 0x1f leaf for SapphireRapids by default

 target/i386/cpu.c     | 346 ++++++++++++++++++++++++++++++++++++++++--
 target/i386/cpu.h     |   9 ++
 target/i386/kvm/kvm.c |   2 +-
 3 files changed, 343 insertions(+), 14 deletions(-)

-- 
2.34.1

[RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
"assert" check blocks adding new cache model for non-AMD CPUs.

Therefore, check the vendor and encode this leaf as all-0 for Intel
CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
check for Zhaoxin as well.

Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
For this case, there is no need to tweak for non-AMD CPUs, because
vendor_cpuid_only has been turned on by default since PC machine v6.1.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1b64ceaaba46..8fdafa8aedaf 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
         break;
     case 0x80000005:
-        /* cache info (L1 cache) */
-        if (cpu->cache_info_passthrough) {
+        /*
+         * cache info (L1 cache)
+         *
+         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
+         * information, i.e., get AMD's cache model. It doesn't matter,
+         * vendor_cpuid_only has been turned on by default since
+         * PC machine v6.1.
+         */
+        if (cpu->vendor_cpuid_only &&
+            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
+            *eax = *ebx = *ecx = *edx = 0;
+            break;
+        } else if (cpu->cache_info_passthrough) {
             x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
             break;
         }
+
         *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
                (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
         *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
-- 
2.34.1

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Xiaoyao Li]

On 4/23/2025 7:46 PM, Zhao Liu wrote:
> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> "assert" check blocks adding new cache model for non-AMD CPUs.
> 
> Therefore, check the vendor and encode this leaf as all-0 for Intel
> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> check for Zhaoxin as well.
> 
> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> For this case, there is no need to tweak for non-AMD CPUs, because
> vendor_cpuid_only has been turned on by default since PC machine v6.1.
> 
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
>   target/i386/cpu.c | 16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1b64ceaaba46..8fdafa8aedaf 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>           *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
>           break;
>       case 0x80000005:
> -        /* cache info (L1 cache) */
> -        if (cpu->cache_info_passthrough) {
> +        /*
> +         * cache info (L1 cache)
> +         *
> +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> +         * information, i.e., get AMD's cache model. It doesn't matter,
> +         * vendor_cpuid_only has been turned on by default since
> +         * PC machine v6.1.
> +         */

We need to define a new compat property for it other than 
vendor_cpuid_only, for 10.1.

I proposed some change to leaf FEAT_8000_0001_EDX[1], and I was told by 
Paolo (privately) that vendor_cpuid_only doesn't suffice.

  On Fri, Oct 11, 2024 at 6:22 PM Xiaoyao Li <xiaoyao.li@intel.com> wrote:
  >
  > On 10/11/2024 11:30 PM, Paolo Bonzini wrote:
  > > On Fri, Oct 11, 2024 at 4:55 PM Xiaoyao Li <xiaoyao.li@intel.com> 
wrote:
  > >>
  > >> I think patch 8 is also a general issue> Without it, the
  > >> CPUID_EXT2_AMD_ALIASES bits are exposed to Intel VMs which are
  > >> reserved bits for Intel.
  > >
  > > Yes but you'd have to add compat properties for these. If you can do
  > > it for TDX only, that's easier.
  >
  > Does vendor_cpuid_only suffice?

  Unfortunately not, because it is turned off only for <=6.0 machine
  types. Here you'd have to turn it off for <=9.1 machine types.


[1] 
https://lore.kernel.org/qemu-devel/20240814075431.339209-9-xiaoyao.li@intel.com/


> +        if (cpu->vendor_cpuid_only &&
> +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> +            *eax = *ebx = *ecx = *edx = 0;
> +            break;
> +        } else if (cpu->cache_info_passthrough) {
>               x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
>               break;
>           }
> +
>           *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
>                  (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>           *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

> > +        /*
> > +         * cache info (L1 cache)
> > +         *
> > +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > +         * information, i.e., get AMD's cache model. It doesn't matter,
> > +         * vendor_cpuid_only has been turned on by default since
> > +         * PC machine v6.1.
> > +         */
> 
> We need to define a new compat property for it other than vendor_cpuid_only,
> for 10.1.
> 
> I proposed some change to leaf FEAT_8000_0001_EDX[1], and I was told by
> Paolo (privately) that vendor_cpuid_only doesn't suffice.
> 
>  On Fri, Oct 11, 2024 at 6:22 PM Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>  >
>  > On 10/11/2024 11:30 PM, Paolo Bonzini wrote:
>  > > On Fri, Oct 11, 2024 at 4:55 PM Xiaoyao Li <xiaoyao.li@intel.com>
> wrote:
>  > >>
>  > >> I think patch 8 is also a general issue> Without it, the
>  > >> CPUID_EXT2_AMD_ALIASES bits are exposed to Intel VMs which are
>  > >> reserved bits for Intel.
>  > >
>  > > Yes but you'd have to add compat properties for these. If you can do
>  > > it for TDX only, that's easier.
>  >
>  > Does vendor_cpuid_only suffice?
> 
>  Unfortunately not, because it is turned off only for <=6.0 machine
>  types. Here you'd have to turn it off for <=9.1 machine types.
> 
> 
> [1] https://lore.kernel.org/qemu-devel/20240814075431.339209-9-xiaoyao.li@intel.com/

For the patch link, you wanted to mark it as unavailiable but it would
break the machine <= 6.0 (with vendor_cpuid_only turned off), correct?

For this patch:
 * vendor_cpuid_only turns off for <= 6.0 machine, no change.
 * vendor_cpuid_only turns on for > 6.0 machine, I treated it as a
   "direct" fix because original codes encode the AMD cache model info
   on non-AMD platform (in ecx & edx). This doesn't make sense. Non-AMD
   platform should use cache_info_cpuid4 or 0 here. If it is considered
   a fix, it may be more appropriate to use cache_info_cpuid4.

I think it's somehow similar to the “trade-offs” Daniel indicated [2].

This case can also be fixed by compat option. Then we don't  need to
encode cache_info_cpuid4 info for non-AMD platforms in this leaf.

Do you still need the patches in your links? (I didn't find the related
patch merged.) If so, I can add the compat option in the next version
which could also help you land your previous patches v10.1 as well.

[2]: https://lore.kernel.org/qemu-devel/Z08j2Ii-QuZk3lTY@redhat.com/

> > +        if (cpu->vendor_cpuid_only &&
> > +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> > +            *eax = *ebx = *ecx = *edx = 0;
> > +            break;
> > +        } else if (cpu->cache_info_passthrough) {
> >               x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
> >               break;
> >           }
> > +
> >           *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
> >                  (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
> >           *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
> 

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 4/23/25 7:46 PM, Zhao Liu wrote:
> 
> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> "assert" check blocks adding new cache model for non-AMD CPUs.
> 
> Therefore, check the vendor and encode this leaf as all-0 for Intel
> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> check for Zhaoxin as well.

Thanks for taking Zhaoxin CPUs into account.

Zhaoxin follows AMD's definition for CPUID leaf 0x80000005, so this leaf is 
valid on our CPUs rather than reserved. We do, however, follow Intel's 
definition for leaf 0x80000006.

> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> For this case, there is no need to tweak for non-AMD CPUs, because
> vendor_cpuid_only has been turned on by default since PC machine v6.1.
> 
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
>   target/i386/cpu.c | 16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1b64ceaaba46..8fdafa8aedaf 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>           *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
>           break;
>       case 0x80000005:
> -        /* cache info (L1 cache) */
> -        if (cpu->cache_info_passthrough) {
> +        /*
> +         * cache info (L1 cache)
> +         *
> +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> +         * information, i.e., get AMD's cache model. It doesn't matter,
> +         * vendor_cpuid_only has been turned on by default since
> +         * PC machine v6.1.
> +         */
> +        if (cpu->vendor_cpuid_only &&
> +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {

Given that, there is no need to add IS_ZHAOXIN_CPU(env) to the 0x80000005 path. 
Note that the L1 TLB constants for the YongFeng core differ from the current 
values in target/i386/cpu.c(YongFeng defaults shown in brackets):

#define L1_DTLB_2M_ASSOC       1 (4)
#define L1_DTLB_2M_ENTRIES   255 (32)
#define L1_DTLB_4K_ASSOC       1 (6)
#define L1_DTLB_4K_ENTRIES   255 (96)

#define L1_ITLB_2M_ASSOC       1 (4)
#define L1_ITLB_2M_ENTRIES   255 (32)
#define L1_ITLB_4K_ASSOC       1 (6)
#define L1_ITLB_4K_ENTRIES   255 (96)

I am still reviewing how these constants flow through cpu_x86_cpuid() for leaf 
0x80000005, so I'm not yet certain whether they are overridden.

For now, the patchset can ignore Zhaoxin in leaf 0x80000005. Once I have traced 
the code path, I will send an update if needed. Please include Zhaoxin in the 
handling for leaf 0x80000006.

I should have sent this after completing my review, but I did not want to delay 
your work. Sorry for the noise.

Thanks again for your work.

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

> On 4/23/25 7:46 PM, Zhao Liu wrote:
> > 
> > Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> > "assert" check blocks adding new cache model for non-AMD CPUs.
> > 
> > Therefore, check the vendor and encode this leaf as all-0 for Intel
> > CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> > check for Zhaoxin as well.
> 
> Thanks for taking Zhaoxin CPUs into account.
> 
> Zhaoxin follows AMD's definition for CPUID leaf 0x80000005, so this leaf is
> valid on our CPUs rather than reserved. We do, however, follow Intel's
> definition for leaf 0x80000006.

Thank you! I'll revert the change.

> > Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> > For this case, there is no need to tweak for non-AMD CPUs, because
> > vendor_cpuid_only has been turned on by default since PC machine v6.1.
> > 
> > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> > ---
> >   target/i386/cpu.c | 16 ++++++++++++++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 1b64ceaaba46..8fdafa8aedaf 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> >           *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
> >           break;
> >       case 0x80000005:
> > -        /* cache info (L1 cache) */
> > -        if (cpu->cache_info_passthrough) {
> > +        /*
> > +         * cache info (L1 cache)
> > +         *
> > +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > +         * information, i.e., get AMD's cache model. It doesn't matter,
> > +         * vendor_cpuid_only has been turned on by default since
> > +         * PC machine v6.1.
> > +         */
> > +        if (cpu->vendor_cpuid_only &&
> > +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> 
> Given that, there is no need to add IS_ZHAOXIN_CPU(env) to the 0x80000005
> path. Note that the L1 TLB constants for the YongFeng core differ from the
> current values in target/i386/cpu.c(YongFeng defaults shown in brackets):
> 
> #define L1_DTLB_2M_ASSOC       1 (4)
> #define L1_DTLB_2M_ENTRIES   255 (32)
> #define L1_DTLB_4K_ASSOC       1 (6)
> #define L1_DTLB_4K_ENTRIES   255 (96)
> 
> #define L1_ITLB_2M_ASSOC       1 (4)
> #define L1_ITLB_2M_ENTRIES   255 (32)
> #define L1_ITLB_4K_ASSOC       1 (6)
> #define L1_ITLB_4K_ENTRIES   255 (96)
> 
> I am still reviewing how these constants flow through cpu_x86_cpuid() for
> leaf 0x80000005, so I'm not yet certain whether they are overridden.
> 
> For now, the patchset can ignore Zhaoxin in leaf 0x80000005. Once I have
> traced the code path, I will send an update if needed. Please include
> Zhaoxin in the handling for leaf 0x80000006.

Sure! And you can add more comment for the special cases.

If possible, could you please help check if there are any other cases :-)
without spec reference, it's easy to cause regression when refactor. As
per Xiaoyao's comment, we would like to further clean up the Intel/AMD
features by minimizing the “incorrect” AMD features in Intel Guests
when vendor_cpuid_only (or another enhanced compat option) is turned on.

> I should have sent this after completing my review, but I did not want to
> delay your work. Sorry for the noise.

No problem. And your info really helps me. It will take me a little
while until the next version. It makes it easier to decouple our work
and review them separately in the community!

> Thanks again for your work.

You're welcome!

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 4/23/25 7:46 PM, Zhao Liu wrote:
> 
> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> "assert" check blocks adding new cache model for non-AMD CPUs.
> 
> Therefore, check the vendor and encode this leaf as all-0 for Intel
> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> check for Zhaoxin as well.
> 
> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> For this case, there is no need to tweak for non-AMD CPUs, because
> vendor_cpuid_only has been turned on by default since PC machine v6.1.
> 
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
>   target/i386/cpu.c | 16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 1b64ceaaba46..8fdafa8aedaf 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>           *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
>           break;
>       case 0x80000005:
> -        /* cache info (L1 cache) */
> -        if (cpu->cache_info_passthrough) {
> +        /*
> +         * cache info (L1 cache)
> +         *
> +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> +         * information, i.e., get AMD's cache model. It doesn't matter,
> +         * vendor_cpuid_only has been turned on by default since
> +         * PC machine v6.1.
> +         */
> +        if (cpu->vendor_cpuid_only &&
> +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> +            *eax = *ebx = *ecx = *edx = 0;
> +            break;
> +        } else if (cpu->cache_info_passthrough) {
>               x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
>               break;
>           }
> +
>           *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
>                  (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>           *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |

I've reviewed the cache-related CPUID path and noticed an oddity: every AMD vCPU 
model still reports identical hard-coded values for the L1 ITLB and L1 DTLB 
fields in leaf 0x8000_0005. Your patch fixes this for Intel(and Zhaoxin), but 
all AMD models continue to receive the same constants in EAX/EBX.

Do you know the reason for this choice? Is the guest expected to ignore those L1 
TLB numbers? If so, I'll prepare a patch that adjusts only the Zhaoxin defaults 
in leaf 0x8000_0005 like below, matching real YongFeng behaviour in ecx and edx, 
but keep eax and ebx following AMD's behaviour.

## Notes
1. Changes tied to "-machine smp-cache xxx" (mainly 
x86_cpu_update_smp_cache_topo()) are not included here.
2. Do you think I need Zhaoxin-specific legacy_l1d/l1i/l2/l3_cache helpers? If 
yes, I'll add them with YongFeng sillicon topology data.

--- patch prototype start ---

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 7b223642ba..8a17e5ffe9 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2726,6 +2726,66 @@ static const CPUCaches xeon_srf_cache_info = {
      },
  };

+static const CPUCaches yongfeng_cache_info = {
+    .l1d_cache = &(CPUCacheInfo) {
+        .type = DATA_CACHE,
+        .level = 1,
+        .size = 32 * KiB,
+        .line_size = 64,
+        .associativity = 8,
+        .partitions = 1,
+        .sets = 64,
+        .lines_per_tag = 1,
+        .inclusive = false,
+        .self_init = true,
+        .no_invd_sharing = false,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l1i_cache = &(CPUCacheInfo) {
+        .type = INSTRUCTION_CACHE,
+        .level = 1,
+        .size = 64 * KiB,
+        .line_size = 64,
+        .associativity = 16,
+        .partitions = 1,
+        .sets = 64,
+        .lines_per_tag = 1,
+        .inclusive = false,
+        .self_init = true,
+        .no_invd_sharing = false,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l2_cache = &(CPUCacheInfo) {
+        .type = UNIFIED_CACHE,
+        .level = 2,
+        .size = 256 * KiB,
+        .line_size = 64,
+        .associativity = 8,
+        .partitions = 1,
+        .sets = 512,
+        .lines_per_tag = 1,
+        .inclusive = true,
+        .self_init = true,
+        .no_invd_sharing = false,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l3_cache = &(CPUCacheInfo) {
+        .type = UNIFIED_CACHE,
+        .level = 3,
+        .size = 8 * MiB,
+        .line_size = 64,
+        .associativity = 16,
+        .partitions = 1,
+        .sets = 8192,
+        .lines_per_tag = 1,
+        .self_init = true,
+        .inclusive = true,
+        .no_invd_sharing = true,
+        .complex_indexing = false,
+        .share_level = CPU_TOPOLOGY_LEVEL_DIE,
+    },
+};
+
  /* The following VMX features are not supported by KVM and are left out in the
   * CPU definitions:
   *
@@ -5928,6 +5988,15 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                      { /* end of list */ }
                  }
              },
+            {
+                .version = 3,
+                .note = "wiith the correct model number and cache info",
+                .props = (PropValue[]) {
+                    { "model", "0x5b" },
+                    { /* end of list */ }
+                },
+                .cache_info = &yongfeng_cache_info
+            },
              { /* end of list */ }
          }
      },
@@ -7565,8 +7634,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
           * vendor_cpuid_only has been turned on by default since
           * PC machine v6.1.
           */
-        if (cpu->vendor_cpuid_only &&
-            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
+        if (cpu->vendor_cpuid_only && IS_INTEL_CPU(env)) {
              *eax = *ebx = *ecx = *edx = 0;
              break;
          } else if (cpu->cache_info_passthrough) {
@@ -7578,8 +7646,21 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
                 (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
          *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
                 (L1_ITLB_4K_ASSOC <<  8) | (L1_ITLB_4K_ENTRIES);
-        *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
-        *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
+
+        if (IS_AMD_CPU(env)) {
+            *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
+            *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
+            break;
+        }
+        /* Zhaoxin follows AMD behaviour on leaf 0x8000_0005 */
+        if (IS_ZHAOXIN_CPU(env)) {
+            *ecx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1d_cache);
+            *edx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1i_cache);
+            break;
+        }
+
+        /* Other vendors */
+        *eax = *ebx = *ecx = *edx = 0;
          break;
      case 0x80000006:
          /* cache info (L2 cache) */
@@ -8638,7 +8719,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
              return;
          }
          env->cache_info_cpuid2 = env->cache_info_cpuid4 = env->cache_info_amd =
-            *cache_info;
+            env->cache_info_zhaoxin = *cache_info;
      } else {
          /* Build legacy cache information */
          env->cache_info_cpuid2.l1d_cache = &legacy_l1d_cache;
@@ -8655,6 +8736,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
          env->cache_info_amd.l1i_cache = &legacy_l1i_cache_amd;
          env->cache_info_amd.l2_cache = &legacy_l2_cache_amd;
          env->cache_info_amd.l3_cache = &legacy_l3_cache;
+
+        env->cache_info_zhaoxin.l1d_cache = &legacy_l1d_cache;
+        env->cache_info_zhaoxin.l1i_cache = &legacy_l1i_cache;
+        env->cache_info_zhaoxin.l2_cache = &legacy_l2_cache;
+        env->cache_info_zhaoxin.l3_cache = &legacy_l3_cache;
      }

  #ifndef CONFIG_USER_ONLY
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index d98c9ba282..46bfd6f6b0 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2062,6 +2062,7 @@ typedef struct CPUArchState {
       * with old QEMU versions.
       */
      CPUCaches cache_info_cpuid2, cache_info_cpuid4, cache_info_amd;
+    CPUCaches cache_info_zhaoxin;

      /* MTRRs */
      uint64_t mtrr_fixed[11];

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

> On 4/23/25 7:46 PM, Zhao Liu wrote:
> > 
> > Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> > "assert" check blocks adding new cache model for non-AMD CPUs.
> > 
> > Therefore, check the vendor and encode this leaf as all-0 for Intel
> > CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> > check for Zhaoxin as well.
> > 
> > Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> > For this case, there is no need to tweak for non-AMD CPUs, because
> > vendor_cpuid_only has been turned on by default since PC machine v6.1.
> > 
> > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> > ---
> >   target/i386/cpu.c | 16 ++++++++++++++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > index 1b64ceaaba46..8fdafa8aedaf 100644
> > --- a/target/i386/cpu.c
> > +++ b/target/i386/cpu.c
> > @@ -7248,11 +7248,23 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
> >           *edx = env->cpuid_model[(index - 0x80000002) * 4 + 3];
> >           break;
> >       case 0x80000005:
> > -        /* cache info (L1 cache) */
> > -        if (cpu->cache_info_passthrough) {
> > +        /*
> > +         * cache info (L1 cache)
> > +         *
> > +         * For !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > +         * information, i.e., get AMD's cache model. It doesn't matter,
> > +         * vendor_cpuid_only has been turned on by default since
> > +         * PC machine v6.1.
> > +         */
> > +        if (cpu->vendor_cpuid_only &&
> > +            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> > +            *eax = *ebx = *ecx = *edx = 0;
> > +            break;
> > +        } else if (cpu->cache_info_passthrough) {
> >               x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
> >               break;
> >           }
> > +
> >           *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
> >                  (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
> >           *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
> 
> I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
> vCPU model still reports identical hard-coded values for the L1 ITLB and L1
> DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
> Zhaoxin), but all AMD models continue to receive the same constants in
> EAX/EBX.

Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
the cache info but didn't cover TLB [*]. I guess one reason would there
are very few use cases related to TLB's info, and people are more
concerned about the cache itself.

[*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/

> Do you know the reason for this choice? Is the guest expected to ignore
> those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
> Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
> behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.

This way is fine for me.

> ## Notes
> 1. Changes tied to "-machine smp-cache xxx" (mainly
> x86_cpu_update_smp_cache_topo()) are not included here.
> 2. Do you think I need Zhaoxin-specific legacy_l1d/l1i/l2/l3_cache helpers?
> If yes, I'll add them with YongFeng sillicon topology data.

Legacy cache info stands for information on very old machines. So I
think your yongfeng_cache_info is enough for Yongfeng CPU.

> --- patch prototype start ---

Thank you for your patch!

> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 7b223642ba..8a17e5ffe9 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2726,6 +2726,66 @@ static const CPUCaches xeon_srf_cache_info = {
>      },
>  };
> 
> +static const CPUCaches yongfeng_cache_info = {
> +    .l1d_cache = &(CPUCacheInfo) {
> +        .type = DATA_CACHE,
> +        .level = 1,
> +        .size = 32 * KiB,
> +        .line_size = 64,
> +        .associativity = 8,
> +        .partitions = 1,
> +        .sets = 64,
> +        .lines_per_tag = 1,
> +        .inclusive = false,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l1i_cache = &(CPUCacheInfo) {
> +        .type = INSTRUCTION_CACHE,
> +        .level = 1,
> +        .size = 64 * KiB,
> +        .line_size = 64,
> +        .associativity = 16,
> +        .partitions = 1,
> +        .sets = 64,
> +        .lines_per_tag = 1,
> +        .inclusive = false,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l2_cache = &(CPUCacheInfo) {
> +        .type = UNIFIED_CACHE,
> +        .level = 2,
> +        .size = 256 * KiB,
> +        .line_size = 64,
> +        .associativity = 8,
> +        .partitions = 1,
> +        .sets = 512,
> +        .lines_per_tag = 1,
> +        .inclusive = true,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l3_cache = &(CPUCacheInfo) {
> +        .type = UNIFIED_CACHE,
> +        .level = 3,
> +        .size = 8 * MiB,
> +        .line_size = 64,
> +        .associativity = 16,
> +        .partitions = 1,
> +        .sets = 8192,
> +        .lines_per_tag = 1,
> +        .self_init = true,
> +        .inclusive = true,
> +        .no_invd_sharing = true,
> +        .complex_indexing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_DIE,

Just to confirm:

Is the topology of cache on your physical machines per-die instead of
per-socket?

> +    },
> +};
> +
>  /* The following VMX features are not supported by KVM and are left out in the
>   * CPU definitions:
>   *
> @@ -5928,6 +5988,15 @@ static const X86CPUDefinition builtin_x86_defs[] = {
>                      { /* end of list */ }
>                  }
>              },
> +            {
> +                .version = 3,
> +                .note = "wiith the correct model number and cache info",
> +                .props = (PropValue[]) {
> +                    { "model", "0x5b" },
> +                    { /* end of list */ }
> +                },
> +                .cache_info = &yongfeng_cache_info
> +            },
>              { /* end of list */ }
>          }
>      },

Adding a cache model can be done as a separate patch. :-)

> @@ -7565,8 +7634,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> uint32_t count,
>           * vendor_cpuid_only has been turned on by default since
>           * PC machine v6.1.
>           */
> -        if (cpu->vendor_cpuid_only &&
> -            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
> +        if (cpu->vendor_cpuid_only && IS_INTEL_CPU(env)) {
>              *eax = *ebx = *ecx = *edx = 0;
>              break;
>          } else if (cpu->cache_info_passthrough) {
> @@ -7578,8 +7646,21 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
> uint32_t count,
>                 (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>          *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
>                 (L1_ITLB_4K_ASSOC <<  8) | (L1_ITLB_4K_ENTRIES);
> -        *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
> -        *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
> +
> +        if (IS_AMD_CPU(env)) {
> +            *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
> +            *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
> +            break;
> +        }

AMD uses 0x80000005 and doesn't use 0x4 leaf. Does Zhaoxin use 0x4?
If not, you can fix 0x4 for Zhaoxin, too.

> +        /* Zhaoxin follows AMD behaviour on leaf 0x8000_0005 */
> +        if (IS_ZHAOXIN_CPU(env)) {
> +            *ecx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1d_cache);
> +            *edx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1i_cache);

Maybe it's not necessary to add cache_info_zhaoxin? Zhaoxin could use
legacy cache_info_cpuid4 with Intel, because it seems cache_info_zhaoxin
is same as cache_info_cpuid4.

For this case, you can add a comment like "This is a special case where
Zhaoxin follows AMD. Elsewhere, Zhaoxin follows Intel's behavior."

> +            break;
> +        }
> +
> +        /* Other vendors */
> +        *eax = *ebx = *ecx = *edx = 0;
>          break;
>      case 0x80000006:
>          /* cache info (L2 cache) */
> @@ -8638,7 +8719,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>              return;
>          }
>          env->cache_info_cpuid2 = env->cache_info_cpuid4 = env->cache_info_amd =
> -            *cache_info;
> +            env->cache_info_zhaoxin = *cache_info;
>      } else {
>          /* Build legacy cache information */
>          env->cache_info_cpuid2.l1d_cache = &legacy_l1d_cache;
> @@ -8655,6 +8736,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>          env->cache_info_amd.l1i_cache = &legacy_l1i_cache_amd;
>          env->cache_info_amd.l2_cache = &legacy_l2_cache_amd;
>          env->cache_info_amd.l3_cache = &legacy_l3_cache;
> +
> +        env->cache_info_zhaoxin.l1d_cache = &legacy_l1d_cache;
> +        env->cache_info_zhaoxin.l1i_cache = &legacy_l1i_cache;
> +        env->cache_info_zhaoxin.l2_cache = &legacy_l2_cache;
> +        env->cache_info_zhaoxin.l3_cache = &legacy_l3_cache;

As I said above, we can apply cache_info_cpuid4 for Zhaoxin too.

>      }
> 
>  #ifndef CONFIG_USER_ONLY
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index d98c9ba282..46bfd6f6b0 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -2062,6 +2062,7 @@ typedef struct CPUArchState {
>       * with old QEMU versions.
>       */
>      CPUCaches cache_info_cpuid2, cache_info_cpuid4, cache_info_amd;
> +    CPUCaches cache_info_zhaoxin;
> 
>      /* MTRRs */
>      uint64_t mtrr_fixed[11];
> 
> 
> 
> 

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 5/27/25 5:15 PM, Zhao Liu wrote:
> 
>> On 4/23/25 7:46 PM, Zhao Liu wrote:
>>>
>>> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
>>> "assert" check blocks adding new cache model for non-AMD CPUs.
>>>
>>> Therefore, check the vendor and encode this leaf as all-0 for Intel
>>> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
>>> check for Zhaoxin as well.
>>>
>>> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
>>> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
>>> For this case, there is no need to tweak for non-AMD CPUs, because
>>> vendor_cpuid_only has been turned on by default since PC machine v6.1.
>>>
>>> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
>>> ---
>>>    target/i386/cpu.c | 16 ++++++++++++++--
>>>    1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>> index 1b64ceaaba46..8fdafa8aedaf 100644
[snip]>>> +
>>>            *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
>>>                   (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>>>            *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
>>
>> I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
>> vCPU model still reports identical hard-coded values for the L1 ITLB and L1
>> DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
>> Zhaoxin), but all AMD models continue to receive the same constants in
>> EAX/EBX.
> 
> Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
> the cache info but didn't cover TLB [*]. I guess one reason would there
> are very few use cases related to TLB's info, and people are more
> concerned about the cache itself.
> 
> [*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/

Understood. Keeping the L1 I/D-TLB fields hard-coded for every vCPU model is 
acceptable.

>> Do you know the reason for this choice? Is the guest expected to ignore
>> those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
>> Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
>> behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.
> 
> This way is fine for me.
> 

Thanks for confirming. I'll post the YongFeng cache-info series once your 
refactor lands.

>> ## Notes
>> 1. Changes tied to "-machine smp-cache xxx" (mainly
>> x86_cpu_update_smp_cache_topo()) are not included here.
>> 2. Do you think I need Zhaoxin-specific legacy_l1d/l1i/l2/l3_cache helpers?
>> If yes, I'll add them with YongFeng sillicon topology data.
> 
> Legacy cache info stands for information on very old machines. So I
> think your yongfeng_cache_info is enough for Yongfeng CPU.
> 
>> --- patch prototype start ---
> 
> Thank you for your patch!
> 
You're welcome!

>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 7b223642ba..8a17e5ffe9 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -2726,6 +2726,66 @@ static const CPUCaches xeon_srf_cache_info = {
>>       },
>>   };
>>
>> +static const CPUCaches yongfeng_cache_info = {
[snip]>> +    .l3_cache = &(CPUCacheInfo) {
>> +        .type = UNIFIED_CACHE,
>> +        .level = 3,
>> +        .size = 8 * MiB,
>> +        .line_size = 64,
>> +        .associativity = 16,
>> +        .partitions = 1,
>> +        .sets = 8192,
>> +        .lines_per_tag = 1,
>> +        .self_init = true,
>> +        .inclusive = true,
>> +        .no_invd_sharing = true,
>> +        .complex_indexing = false,
>> +        .share_level = CPU_TOPOLOGY_LEVEL_DIE,
> 
> Just to confirm:
> 
> Is the topology of cache on your physical machines per-die instead of
> per-socket?
> 
Apologies for the confusion, the code I shared was only a prototype.
Before submitting the real patch I'll verify every value in yongfeng_cache_info 
against silicon.

For YongFeng the hierarchy is: L1/L2 shared per core, L3 shared per die (four 
cores per L3).

>> +    },
>> +};
>> +
>>   /* The following VMX features are not supported by KVM and are left out in the
>>    * CPU definitions:
>>    *
>> @@ -5928,6 +5988,15 @@ static const X86CPUDefinition builtin_x86_defs[] = {
>>                       { /* end of list */ }
>>                   }
>>               },
>> +            {
>> +                .version = 3,
>> +                .note = "wiith the correct model number and cache info",
>> +                .props = (PropValue[]) {
>> +                    { "model", "0x5b" },
>> +                    { /* end of list */ }
>> +                },
>> +                .cache_info = &yongfeng_cache_info
>> +            },
>>               { /* end of list */ }
>>           }
>>       },
> 
> Adding a cache model can be done as a separate patch. :-)
Ok, the current blob was for review only; the formal submission will be split 
into logical patches.>
>> @@ -7565,8 +7634,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
>> uint32_t count,
>>            * vendor_cpuid_only has been turned on by default since
>>            * PC machine v6.1.
>>            */
>> -        if (cpu->vendor_cpuid_only &&
>> -            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
>> +        if (cpu->vendor_cpuid_only && IS_INTEL_CPU(env)) {
>>               *eax = *ebx = *ecx = *edx = 0;
>>               break;
>>           } else if (cpu->cache_info_passthrough) {
>> @@ -7578,8 +7646,21 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
>> uint32_t count,
>>                  (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>>           *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
>>                  (L1_ITLB_4K_ASSOC <<  8) | (L1_ITLB_4K_ENTRIES);
>> -        *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
>> -        *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
>> +
>> +        if (IS_AMD_CPU(env)) {
>> +            *ecx = encode_cache_cpuid80000005(env->cache_info_amd.l1d_cache);
>> +            *edx = encode_cache_cpuid80000005(env->cache_info_amd.l1i_cache);
>> +            break;
>> +        }
> 
> AMD uses 0x80000005 and doesn't use 0x4 leaf. Does Zhaoxin use 0x4?
> If not, you can fix 0x4 for Zhaoxin, too.
Zhaoxin uses 0x4 like Intel. We don't need to fix cpuid 0x4 leaf behaviour.>
>> +        /* Zhaoxin follows AMD behaviour on leaf 0x8000_0005 */
>> +        if (IS_ZHAOXIN_CPU(env)) {
>> +            *ecx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1d_cache);
>> +            *edx = encode_cache_cpuid80000005(env->cache_info_zhaoxin.l1i_cache);
> 
> Maybe it's not necessary to add cache_info_zhaoxin? Zhaoxin could use
> legacy cache_info_cpuid4 with Intel, because it seems cache_info_zhaoxin
> is same as cache_info_cpuid4.
> 
> For this case, you can add a comment like "This is a special case where
> Zhaoxin follows AMD. Elsewhere, Zhaoxin follows Intel's behavior."
I agree! I'll drop the cache_info_zhaoxin stub and reuse cache_info_cpuid4 in 
the final patch set.>
>> +            break;
>> +        }
>> +
>> +        /* Other vendors */
>> +        *eax = *ebx = *ecx = *edx = 0;
>>           break;
>>       case 0x80000006:
>>           /* cache info (L2 cache) */
>> @@ -8638,7 +8719,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>>               return;
>>           }
>>           env->cache_info_cpuid2 = env->cache_info_cpuid4 = env->cache_info_amd =
>> -            *cache_info;
>> +            env->cache_info_zhaoxin = *cache_info;
>>       } else {
>>           /* Build legacy cache information */
>>           env->cache_info_cpuid2.l1d_cache = &legacy_l1d_cache;
>> @@ -8655,6 +8736,11 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
>>           env->cache_info_amd.l1i_cache = &legacy_l1i_cache_amd;
>>           env->cache_info_amd.l2_cache = &legacy_l2_cache_amd;
>>           env->cache_info_amd.l3_cache = &legacy_l3_cache;
>> +
>> +        env->cache_info_zhaoxin.l1d_cache = &legacy_l1d_cache;
>> +        env->cache_info_zhaoxin.l1i_cache = &legacy_l1i_cache;
>> +        env->cache_info_zhaoxin.l2_cache = &legacy_l2_cache;
>> +        env->cache_info_zhaoxin.l3_cache = &legacy_l3_cache;
> 
> As I said above, we can apply cache_info_cpuid4 for Zhaoxin too.
Yep!> >>       }
[snip]

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

On Tue, May 27, 2025 at 05:56:07PM +0800, Ewan Hai wrote:
> Date: Tue, 27 May 2025 17:56:07 +0800
> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
> Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
>  Intel
> 
> 
> 
> On 5/27/25 5:15 PM, Zhao Liu wrote:
> > 
> > > On 4/23/25 7:46 PM, Zhao Liu wrote:
> > > > 
> > > > Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> > > > "assert" check blocks adding new cache model for non-AMD CPUs.
> > > > 
> > > > Therefore, check the vendor and encode this leaf as all-0 for Intel
> > > > CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> > > > check for Zhaoxin as well.
> > > > 
> > > > Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > > > information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> > > > For this case, there is no need to tweak for non-AMD CPUs, because
> > > > vendor_cpuid_only has been turned on by default since PC machine v6.1.
> > > > 
> > > > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> > > > ---
> > > >    target/i386/cpu.c | 16 ++++++++++++++--
> > > >    1 file changed, 14 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > index 1b64ceaaba46..8fdafa8aedaf 100644
> [snip]>>> +
> > > >            *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
> > > >                   (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
> > > >            *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
> > > 
> > > I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
> > > vCPU model still reports identical hard-coded values for the L1 ITLB and L1
> > > DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
> > > Zhaoxin), but all AMD models continue to receive the same constants in
> > > EAX/EBX.
> > 
> > Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
> > the cache info but didn't cover TLB [*]. I guess one reason would there
> > are very few use cases related to TLB's info, and people are more
> > concerned about the cache itself.
> > 
> > [*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/
> 
> Understood. Keeping the L1 I/D-TLB fields hard-coded for every vCPU model is
> acceptable.
> 
> > > Do you know the reason for this choice? Is the guest expected to ignore
> > > those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
> > > Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
> > > behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.
> > 
> > This way is fine for me.
> > 
> 
> Thanks for confirming. I'll post the YongFeng cache-info series once your
> refactor lands.

Hi Ewan,

By this patch:

https://lore.kernel.org/qemu-devel/20250620092734.1576677-14-zhao1.liu@intel.com/

I fixed the 0x80000005 leaf for Intel and Zhaoxin based on your feedback
by the way.

It looks like the unified cache_info would be very compatible with
various vendor needs and corner cases. So I'll respin this series based
on that cache_info series.

Before sending the patch, I was thinking that maybe I could help you
rebase and include your Yongfeng cache model patch you added into my v2
series, or you could rebase and send it yourself afterward. Which way do
you like?

And for TLB, we can wait and see what maintainers think. Maybe it is
possible, considering that the cache also transitioned from hardcoding
to a cache model (since commit 7e3482f82480).

Thanks,
Zhao

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 6/24/25 3:22 PM, Zhao Liu wrote:
> 
> On Tue, May 27, 2025 at 05:56:07PM +0800, Ewan Hai wrote:
>> Date: Tue, 27 May 2025 17:56:07 +0800
>> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
>> Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
>>   Intel
>>
>>
>>
>> On 5/27/25 5:15 PM, Zhao Liu wrote:
>>>
>>>> On 4/23/25 7:46 PM, Zhao Liu wrote:
>>>>>
>>>>> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
>>>>> "assert" check blocks adding new cache model for non-AMD CPUs.
>>>>>
>>>>> Therefore, check the vendor and encode this leaf as all-0 for Intel
>>>>> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
>>>>> check for Zhaoxin as well.
>>>>>
>>>>> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
>>>>> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
>>>>> For this case, there is no need to tweak for non-AMD CPUs, because
>>>>> vendor_cpuid_only has been turned on by default since PC machine v6.1.
>>>>>
>>>>> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
>>>>> ---
>>>>>     target/i386/cpu.c | 16 ++++++++++++++--
>>>>>     1 file changed, 14 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>>>> index 1b64ceaaba46..8fdafa8aedaf 100644
>> [snip]>>> +
>>>>>             *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
>>>>>                    (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>>>>>             *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
>>>>
>>>> I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
>>>> vCPU model still reports identical hard-coded values for the L1 ITLB and L1
>>>> DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
>>>> Zhaoxin), but all AMD models continue to receive the same constants in
>>>> EAX/EBX.
>>>
>>> Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
>>> the cache info but didn't cover TLB [*]. I guess one reason would there
>>> are very few use cases related to TLB's info, and people are more
>>> concerned about the cache itself.
>>>
>>> [*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/
>>
>> Understood. Keeping the L1 I/D-TLB fields hard-coded for every vCPU model is
>> acceptable.
>>
>>>> Do you know the reason for this choice? Is the guest expected to ignore
>>>> those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
>>>> Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
>>>> behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.
>>>
>>> This way is fine for me.
>>>
>>
>> Thanks for confirming. I'll post the YongFeng cache-info series once your
>> refactor lands.
> 
> Hi Ewan,
> 
> By this patch:
> 
> https://lore.kernel.org/qemu-devel/20250620092734.1576677-14-zhao1.liu@intel.com/
> 
> I fixed the 0x80000005 leaf for Intel and Zhaoxin based on your feedback
> by the way.
> 
> It looks like the unified cache_info would be very compatible with
> various vendor needs and corner cases. So I'll respin this series based
> on that cache_info series.
> 
> Before sending the patch, I was thinking that maybe I could help you
> rebase and include your Yongfeng cache model patch you added into my v2
> series, or you could rebase and send it yourself afterward. Which way do
> you like?

It would be great if you could include the Yongfeng cache-model patch in your v2 
series. Let me know if you need any more information about the Yongfeng cache 
model. After you submit v2, I can review the Zhaoxin parts and make any 
necessary code changes if needed.

And thanks again for taking Zhaoxin into account.

> 
> And for TLB, we can wait and see what maintainers think. Maybe it is
> possible, considering that the cache also transitioned from hardcoding
> to a cache model (since commit 7e3482f82480).
> 
Let's wait.> Thanks,
> Zhao
> 

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

On Tue, Jun 24, 2025 at 07:04:02PM +0800, Ewan Hai wrote:
> Date: Tue, 24 Jun 2025 19:04:02 +0800
> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
> Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
>  Intel
> 
> 
> 
> On 6/24/25 3:22 PM, Zhao Liu wrote:
> > 
> > On Tue, May 27, 2025 at 05:56:07PM +0800, Ewan Hai wrote:
> > > Date: Tue, 27 May 2025 17:56:07 +0800
> > > From: Ewan Hai <ewanhai-oc@zhaoxin.com>
> > > Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
> > >   Intel
> > > 
> > > 
> > > 
> > > On 5/27/25 5:15 PM, Zhao Liu wrote:
> > > > 
> > > > > On 4/23/25 7:46 PM, Zhao Liu wrote:
> > > > > > 
> > > > > > Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
> > > > > > "assert" check blocks adding new cache model for non-AMD CPUs.
> > > > > > 
> > > > > > Therefore, check the vendor and encode this leaf as all-0 for Intel
> > > > > > CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
> > > > > > check for Zhaoxin as well.
> > > > > > 
> > > > > > Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
> > > > > > information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
> > > > > > For this case, there is no need to tweak for non-AMD CPUs, because
> > > > > > vendor_cpuid_only has been turned on by default since PC machine v6.1.
> > > > > > 
> > > > > > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> > > > > > ---
> > > > > >     target/i386/cpu.c | 16 ++++++++++++++--
> > > > > >     1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > > > > index 1b64ceaaba46..8fdafa8aedaf 100644
> > > [snip]>>> +
> > > > > >             *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
> > > > > >                    (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
> > > > > >             *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
> > > > > 
> > > > > I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
> > > > > vCPU model still reports identical hard-coded values for the L1 ITLB and L1
> > > > > DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
> > > > > Zhaoxin), but all AMD models continue to receive the same constants in
> > > > > EAX/EBX.
> > > > 
> > > > Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
> > > > the cache info but didn't cover TLB [*]. I guess one reason would there
> > > > are very few use cases related to TLB's info, and people are more
> > > > concerned about the cache itself.
> > > > 
> > > > [*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/
> > > 
> > > Understood. Keeping the L1 I/D-TLB fields hard-coded for every vCPU model is
> > > acceptable.
> > > 
> > > > > Do you know the reason for this choice? Is the guest expected to ignore
> > > > > those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
> > > > > Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
> > > > > behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.
> > > > 
> > > > This way is fine for me.
> > > > 
> > > 
> > > Thanks for confirming. I'll post the YongFeng cache-info series once your
> > > refactor lands.
> > 
> > Hi Ewan,
> > 
> > By this patch:
> > 
> > https://lore.kernel.org/qemu-devel/20250620092734.1576677-14-zhao1.liu@intel.com/
> > 
> > I fixed the 0x80000005 leaf for Intel and Zhaoxin based on your feedback
> > by the way.
> > 
> > It looks like the unified cache_info would be very compatible with
> > various vendor needs and corner cases. So I'll respin this series based
> > on that cache_info series.
> > 
> > Before sending the patch, I was thinking that maybe I could help you
> > rebase and include your Yongfeng cache model patch you added into my v2
> > series, or you could rebase and send it yourself afterward. Which way do
> > you like?
> 
> It would be great if you could include the Yongfeng cache-model patch in
> your v2 series. Let me know if you need any more information about the
> Yongfeng cache model. After you submit v2, I can review the Zhaoxin parts
> and make any necessary code changes if needed.
> 
> And thanks again for taking Zhaoxin into account.

Welcome; it's something I can easily help with. If possible, when v2 is
out, hope you could help test it on your platform to ensure everything
is fine. :-) And I've verified it myself through TCG.

Thanks,
Zhao

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 6/25/25 11:03 AM, Zhao Liu wrote:
> 
> 
> On Tue, Jun 24, 2025 at 07:04:02PM +0800, Ewan Hai wrote:
>> Date: Tue, 24 Jun 2025 19:04:02 +0800
>> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
>> Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
>>   Intel
>>
>>
>>
>> On 6/24/25 3:22 PM, Zhao Liu wrote:
>>>
>>> On Tue, May 27, 2025 at 05:56:07PM +0800, Ewan Hai wrote:
>>>> Date: Tue, 27 May 2025 17:56:07 +0800
>>>> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
>>>> Subject: Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for
>>>>    Intel
>>>>
>>>>
>>>>
>>>> On 5/27/25 5:15 PM, Zhao Liu wrote:
>>>>>
>>>>>> On 4/23/25 7:46 PM, Zhao Liu wrote:
>>>>>>>
>>>>>>> Per SDM, 0x80000005 leaf is reserved for Intel CPU, and its current
>>>>>>> "assert" check blocks adding new cache model for non-AMD CPUs.
>>>>>>>
>>>>>>> Therefore, check the vendor and encode this leaf as all-0 for Intel
>>>>>>> CPU. And since Zhaoxin mostly follows Intel behavior, apply the vendor
>>>>>>> check for Zhaoxin as well.
>>>>>>>
>>>>>>> Note, for !vendor_cpuid_only case, non-AMD CPU would get the wrong
>>>>>>> information, i.e., get AMD's cache model for Intel or Zhaoxin CPUs.
>>>>>>> For this case, there is no need to tweak for non-AMD CPUs, because
>>>>>>> vendor_cpuid_only has been turned on by default since PC machine v6.1.
>>>>>>>
>>>>>>> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
>>>>>>> ---
>>>>>>>      target/i386/cpu.c | 16 ++++++++++++++--
>>>>>>>      1 file changed, 14 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>>>>>>> index 1b64ceaaba46..8fdafa8aedaf 100644
>>>> [snip]>>> +
>>>>>>>              *eax = (L1_DTLB_2M_ASSOC << 24) | (L1_DTLB_2M_ENTRIES << 16) |
>>>>>>>                     (L1_ITLB_2M_ASSOC <<  8) | (L1_ITLB_2M_ENTRIES);
>>>>>>>              *ebx = (L1_DTLB_4K_ASSOC << 24) | (L1_DTLB_4K_ENTRIES << 16) |
>>>>>>
>>>>>> I've reviewed the cache-related CPUID path and noticed an oddity: every AMD
>>>>>> vCPU model still reports identical hard-coded values for the L1 ITLB and L1
>>>>>> DTLB fields in leaf 0x8000_0005. Your patch fixes this for Intel(and
>>>>>> Zhaoxin), but all AMD models continue to receive the same constants in
>>>>>> EAX/EBX.
>>>>>
>>>>> Yes, TLB info is hardcoded here. Previously, Babu and Eduardo cleaned up
>>>>> the cache info but didn't cover TLB [*]. I guess one reason would there
>>>>> are very few use cases related to TLB's info, and people are more
>>>>> concerned about the cache itself.
>>>>>
>>>>> [*]: https://lore.kernel.org/qemu-devel/20180510204148.11687-2-babu.moger@amd.com/
>>>>
>>>> Understood. Keeping the L1 I/D-TLB fields hard-coded for every vCPU model is
>>>> acceptable.
>>>>
>>>>>> Do you know the reason for this choice? Is the guest expected to ignore
>>>>>> those L1 TLB numbers? If so, I'll prepare a patch that adjusts only the
>>>>>> Zhaoxin defaults in leaf 0x8000_0005 like below, matching real YongFeng
>>>>>> behaviour in ecx and edx, but keep eax and ebx following AMD's behaviour.
>>>>>
>>>>> This way is fine for me.
>>>>>
>>>>
>>>> Thanks for confirming. I'll post the YongFeng cache-info series once your
>>>> refactor lands.
>>>
>>> Hi Ewan,
>>>
>>> By this patch:
>>>
>>> https://lore.kernel.org/qemu-devel/20250620092734.1576677-14-zhao1.liu@intel.com/
>>>
>>> I fixed the 0x80000005 leaf for Intel and Zhaoxin based on your feedback
>>> by the way.
>>>
>>> It looks like the unified cache_info would be very compatible with
>>> various vendor needs and corner cases. So I'll respin this series based
>>> on that cache_info series.
>>>
>>> Before sending the patch, I was thinking that maybe I could help you
>>> rebase and include your Yongfeng cache model patch you added into my v2
>>> series, or you could rebase and send it yourself afterward. Which way do
>>> you like?
>>
>> It would be great if you could include the Yongfeng cache-model patch in
>> your v2 series. Let me know if you need any more information about the
>> Yongfeng cache model. After you submit v2, I can review the Zhaoxin parts
>> and make any necessary code changes if needed.
>>
>> And thanks again for taking Zhaoxin into account.
> 
> Welcome; it's something I can easily help with. If possible, when v2 is
> out, hope you could help test it on your platform to ensure everything
> is fine. :-) And I've verified it myself through TCG.
> 
There's no problem!> Thanks,
> Zhao
> 

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Zhao Liu]

Just want to confirm with the "lines_per_tag" field, which is related
about how to handle current "assert(lines_per_tag > 0)":

> --- patch prototype start ---
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 7b223642ba..8a17e5ffe9 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2726,6 +2726,66 @@ static const CPUCaches xeon_srf_cache_info = {
>      },
>  };
> 
> +static const CPUCaches yongfeng_cache_info = {
> +    .l1d_cache = &(CPUCacheInfo) {
> +        .type = DATA_CACHE,
> +        .level = 1,
> +        .size = 32 * KiB,
> +        .line_size = 64,
> +        .associativity = 8,
> +        .partitions = 1,
> +        .sets = 64,
> +        .lines_per_tag = 1,

This fits AMD APM, and is fine.

> +        .inclusive = false,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l1i_cache = &(CPUCacheInfo) {
> +        .type = INSTRUCTION_CACHE,
> +        .level = 1,
> +        .size = 64 * KiB,
> +        .line_size = 64,
> +        .associativity = 16,
> +        .partitions = 1,
> +        .sets = 64,
> +        .lines_per_tag = 1,

Fine, too.

> +        .inclusive = false,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l2_cache = &(CPUCacheInfo) {
> +        .type = UNIFIED_CACHE,
> +        .level = 2,
> +        .size = 256 * KiB,
> +        .line_size = 64,
> +        .associativity = 8,
> +        .partitions = 1,
> +        .sets = 512,
> +        .lines_per_tag = 1,

SDM reserves this field:

For 0x80000006 ECX:

Bits 11-08: Reserved.

So I think this field should be 0, to align with "Reserved".

In this patch:

https://lore.kernel.org/qemu-devel/20250620092734.1576677-9-zhao1.liu@intel.com/

I add an argument (lines_per_tag_supported) in encode_cache_cpuid80000006(),
and for the case that lines_per_tag_supported=false, I assert
"lines_per_tag == 0" to align with "Reserved".

> +        .inclusive = true,
> +        .self_init = true,
> +        .no_invd_sharing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l3_cache = &(CPUCacheInfo) {
> +        .type = UNIFIED_CACHE,
> +        .level = 3,
> +        .size = 8 * MiB,
> +        .line_size = 64,
> +        .associativity = 16,
> +        .partitions = 1,
> +        .sets = 8192,
> +        .lines_per_tag = 1,

The 0x80000006 EDX is also reserved in SDM. So I think this field should
be 0, too.

Do you agree?

> +        .self_init = true,
> +        .inclusive = true,
> +        .no_invd_sharing = true,
> +        .complex_indexing = false,
> +        .share_level = CPU_TOPOLOGY_LEVEL_DIE,
> +    },
> +};
> +

Re: [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel

[Ewan Hai]

On 6/25/25 5:19 PM, Zhao Liu wrote:
> 
> 
> Just want to confirm with the "lines_per_tag" field, which is related
> about how to handle current "assert(lines_per_tag > 0)":
> 
>> --- patch prototype start ---
>>
>> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
>> index 7b223642ba..8a17e5ffe9 100644
>> --- a/target/i386/cpu.c
>> +++ b/target/i386/cpu.c
>> @@ -2726,6 +2726,66 @@ static const CPUCaches xeon_srf_cache_info = {
>>       },
>>   };
>>
>> +static const CPUCaches yongfeng_cache_info = {
>> +    .l1d_cache = &(CPUCacheInfo) {
>> +        .type = DATA_CACHE,
>> +        .level = 1,
>> +        .size = 32 * KiB,
>> +        .line_size = 64,
>> +        .associativity = 8,
>> +        .partitions = 1,
>> +        .sets = 64,
>> +        .lines_per_tag = 1,
> 
> This fits AMD APM, and is fine.
> 
>> +        .inclusive = false,
>> +        .self_init = true,
>> +        .no_invd_sharing = false,
>> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
>> +    },
>> +    .l1i_cache = &(CPUCacheInfo) {
>> +        .type = INSTRUCTION_CACHE,
>> +        .level = 1,
>> +        .size = 64 * KiB,
>> +        .line_size = 64,
>> +        .associativity = 16,
>> +        .partitions = 1,
>> +        .sets = 64,
>> +        .lines_per_tag = 1,
> 
> Fine, too.
> 
>> +        .inclusive = false,
>> +        .self_init = true,
>> +        .no_invd_sharing = false,
>> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
>> +    },
>> +    .l2_cache = &(CPUCacheInfo) {
>> +        .type = UNIFIED_CACHE,
>> +        .level = 2,
>> +        .size = 256 * KiB,
>> +        .line_size = 64,
>> +        .associativity = 8,
>> +        .partitions = 1,
>> +        .sets = 512,
>> +        .lines_per_tag = 1,
> 
> SDM reserves this field:
> 
> For 0x80000006 ECX:
> 
> Bits 11-08: Reserved.
> 
> So I think this field should be 0, to align with "Reserved".

I agree. For Zhaoxin, the "lines-per-tag" field appears only in CPUID leaf 
0x80000005. Because Zhaoxin follows AMD behavior on this leaf, and the AMD 
manual states that it reports L1 cache/TLB information, so any "lines-per-tag" 
value for levels other than L1 should be omitted or set to zero.

> 
> In this patch:
> 
> https://lore.kernel.org/qemu-devel/20250620092734.1576677-9-zhao1.liu@intel.com/
> 
> I add an argument (lines_per_tag_supported) in encode_cache_cpuid80000006(),
> and for the case that lines_per_tag_supported=false, I assert
> "lines_per_tag == 0" to align with "Reserved".
> 
>> +        .inclusive = true,
>> +        .self_init = true,
>> +        .no_invd_sharing = false,
>> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
>> +    },
>> +    .l3_cache = &(CPUCacheInfo) {
>> +        .type = UNIFIED_CACHE,
>> +        .level = 3,
>> +        .size = 8 * MiB,
>> +        .line_size = 64,
>> +        .associativity = 16,
>> +        .partitions = 1,
>> +        .sets = 8192,
>> +        .lines_per_tag = 1,
> 
> The 0x80000006 EDX is also reserved in SDM. So I think this field should
> be 0, too.
> 
> Do you agree?

Ditto.>
>> +        .self_init = true,
>> +        .inclusive = true,
>> +        .no_invd_sharing = true,
>> +        .complex_indexing = false,
>> +        .share_level = CPU_TOPOLOGY_LEVEL_DIE,
>> +    },
>> +};
>> +

[RFC 02/10] i386/cpu: Fix CPUID[0x80000006] for Intel CPU

[Zhao Liu]

Per SDM, Intel supports CPUID[0x80000006]. But only L2 information is
encoded in ECX (note that L2 associativity field encodings rules
consistent with AMD are used), all other fields are reserved.

Therefore, make the following changes to CPUID[0x80000006]:
 * Rename AMD_ENC_ASSOC to X86_ENC_ASSOC since Intel also uses the same
   rules. (While there are some slight differences between the rules in
   AMD APM v4.07 no.40332 and those in the current QEMU, generally they
   are consistent.)
 * Check the vendor in CPUID[0x80000006] and just encode L2 to ECX for
   Intel.
 * Assert L2's lines_per_tag is not 0 for AMD, and assert it is 0 for
   Intel.
 * Apply the encoding change of Intel for Zhaoxin as well.

Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 28 +++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 8fdafa8aedaf..5119d7aa4150 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -436,8 +436,8 @@ static uint32_t encode_cache_cpuid80000005(CPUCacheInfo *cache)
 
 #define ASSOC_FULL 0xFF
 
-/* AMD associativity encoding used on CPUID Leaf 0x80000006: */
-#define AMD_ENC_ASSOC(a) (a <=   1 ? a   : \
+/* x86 associativity encoding used on CPUID Leaf 0x80000006: */
+#define X86_ENC_ASSOC(a) (a <=   1 ? a   : \
                           a ==   2 ? 0x2 : \
                           a ==   4 ? 0x4 : \
                           a ==   8 ? 0x6 : \
@@ -460,19 +460,19 @@ static void encode_cache_cpuid80000006(CPUCacheInfo *l2,
 {
     assert(l2->size % 1024 == 0);
     assert(l2->associativity > 0);
-    assert(l2->lines_per_tag > 0);
     assert(l2->line_size > 0);
     *ecx = ((l2->size / 1024) << 16) |
-           (AMD_ENC_ASSOC(l2->associativity) << 12) |
+           (X86_ENC_ASSOC(l2->associativity) << 12) |
            (l2->lines_per_tag << 8) | (l2->line_size);
 
+    /* For Intel, EDX is reserved. */
     if (l3) {
         assert(l3->size % (512 * 1024) == 0);
         assert(l3->associativity > 0);
         assert(l3->lines_per_tag > 0);
         assert(l3->line_size > 0);
         *edx = ((l3->size / (512 * 1024)) << 18) |
-               (AMD_ENC_ASSOC(l3->associativity) << 12) |
+               (X86_ENC_ASSOC(l3->associativity) << 12) |
                (l3->lines_per_tag << 8) | (l3->line_size);
     } else {
         *edx = 0;
@@ -7277,15 +7277,25 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         if (cpu->cache_info_passthrough) {
             x86_cpu_get_cache_cpuid(index, 0, eax, ebx, ecx, edx);
             break;
+        } else if (cpu->vendor_cpuid_only &&
+            (IS_INTEL_CPU(env) || IS_ZHAOXIN_CPU(env))) {
+            *eax = *ebx = 0;
+            assert(env->cache_info_cpuid4.l2_cache->lines_per_tag == 0);
+            encode_cache_cpuid80000006(env->cache_info_cpuid4.l2_cache,
+                                       NULL, ecx, edx);
+            break;
         }
-        *eax = (AMD_ENC_ASSOC(L2_DTLB_2M_ASSOC) << 28) |
+
+        *eax = (X86_ENC_ASSOC(L2_DTLB_2M_ASSOC) << 28) |
                (L2_DTLB_2M_ENTRIES << 16) |
-               (AMD_ENC_ASSOC(L2_ITLB_2M_ASSOC) << 12) |
+               (X86_ENC_ASSOC(L2_ITLB_2M_ASSOC) << 12) |
                (L2_ITLB_2M_ENTRIES);
-        *ebx = (AMD_ENC_ASSOC(L2_DTLB_4K_ASSOC) << 28) |
+        *ebx = (X86_ENC_ASSOC(L2_DTLB_4K_ASSOC) << 28) |
                (L2_DTLB_4K_ENTRIES << 16) |
-               (AMD_ENC_ASSOC(L2_ITLB_4K_ASSOC) << 12) |
+               (X86_ENC_ASSOC(L2_ITLB_4K_ASSOC) << 12) |
                (L2_ITLB_4K_ENTRIES);
+
+        assert(env->cache_info_amd.l2_cache->lines_per_tag > 0);
         encode_cache_cpuid80000006(env->cache_info_amd.l2_cache,
                                    cpu->enable_l3_cache ?
                                    env->cache_info_amd.l3_cache : NULL,
-- 
2.34.1

[RFC 03/10] i386/cpu: Introduce cache model for SierraForest

[Zhao Liu]

Add the cache model to SierraForest (v3) to better emulate its
environment.

The cache model is based on SierraForest-SP (Scalable Performance):

      --- cache 0 ---
      cache type                         = data cache (1)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x0 (0)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x8 (8)
      number of sets                     = 0x40 (64)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 64
      (size synth)                       = 32768 (32 KB)
      --- cache 1 ---
      cache type                         = instruction cache (2)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x0 (0)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x8 (8)
      number of sets                     = 0x80 (128)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 128
      (size synth)                       = 65536 (64 KB)
      --- cache 2 ---
      cache type                         = unified cache (3)
      cache level                        = 0x2 (2)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x7 (7)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x10 (16)
      number of sets                     = 0x1000 (4096)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 4096
      (size synth)                       = 4194304 (4 MB)
      --- cache 3 ---
      cache type                         = unified cache (3)
      cache level                        = 0x3 (3)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1ff (511)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0xc (12)
      number of sets                     = 0x24000 (147456)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = true
      number of sets (s)                 = 147456
      (size synth)                       = 113246208 (108 MB)
      --- cache 4 ---
      cache type                         = no more caches (0)

Suggested-by: Tejus GK <tejus.gk@nutanix.com>
Suggested-by: Jason Zeng <jason.zeng@intel.com>
Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5119d7aa4150..4f7ab6246e39 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2453,6 +2453,97 @@ static const CPUCaches epyc_genoa_cache_info = {
     },
 };
 
+static const CPUCaches xeon_srf_cache_info = {
+    .l1d_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x0.EAX
+        .type = DATA_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x0.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 8,
+
+        // CPUID 0x4.0x0.ECX
+        .sets = 64,
+
+        // CPUID 0x4.0x0.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 32 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l1i_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x1.EAX
+        .type = INSTRUCTION_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x1.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 8,
+
+        // CPUID 0x4.0x1.ECX
+        .sets = 128,
+
+        // CPUID 0x4.0x1.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 64 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l2_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x2.EAX
+        .type = UNIFIED_CACHE,
+        .level = 2,
+        .self_init = true,
+
+        // CPUID 0x4.0x2.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 16,
+
+        // CPUID 0x4.0x2.ECX
+        .sets = 4096,
+
+        // CPUID 0x4.0x2.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 4 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_MODULE,
+    },
+    .l3_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x3.EAX
+        .type = UNIFIED_CACHE,
+        .level = 3,
+        .self_init = true,
+
+        // CPUID 0x4.0x3.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 12,
+
+        // CPUID 0x4.0x3.ECX
+        .sets = 147456,
+
+        // CPUID 0x4.0x3.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = true,
+
+        .size = 108 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_SOCKET,
+    },
+};
+
 /* The following VMX features are not supported by KVM and are left out in the
  * CPU definitions:
  *
@@ -4571,6 +4662,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                     { /* end of list */ }
                 }
             },
+            {
+                .version = 3,
+                .note = "with srf-sp cache model",
+                .cache_info = &xeon_srf_cache_info,
+            },
             { /* end of list */ },
         },
     },
-- 
2.34.1

[RFC 04/10] i386/cpu: Introduce cache model for GraniteRapids

[Zhao Liu]

Add the cache model to GraniteRapids (v3) to better emulate its
environment.

The cache model is based on GraniteRapids-SP (Scalable Performance):

      --- cache 0 ---
      cache type                         = data cache (1)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0xc (12)
      number of sets                     = 0x40 (64)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 64
      (size synth)                       = 49152 (48 KB)
      --- cache 1 ---
      cache type                         = instruction cache (2)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x10 (16)
      number of sets                     = 0x40 (64)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 64
      (size synth)                       = 65536 (64 KB)
      --- cache 2 ---
      cache type                         = unified cache (3)
      cache level                        = 0x2 (2)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x10 (16)
      number of sets                     = 0x800 (2048)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 2048
      (size synth)                       = 2097152 (2 MB)
      --- cache 3 ---
      cache type                         = unified cache (3)
      cache level                        = 0x3 (3)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0xff (255)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x10 (16)
      number of sets                     = 0x48000 (294912)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = true
      number of sets (s)                 = 294912
      (size synth)                       = 301989888 (288 MB)
      --- cache 4 ---
      cache type                         = no more caches (0)

Suggested-by: Tejus GK <tejus.gk@nutanix.com>
Suggested-by: Jason Zeng <jason.zeng@intel.com>
Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4f7ab6246e39..00e4a8372c28 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2453,6 +2453,97 @@ static const CPUCaches epyc_genoa_cache_info = {
     },
 };
 
+static const CPUCaches xeon_gnr_cache_info = {
+    .l1d_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x0.EAX
+        .type = DATA_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x0.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 12,
+
+        // CPUID 0x4.0x0.ECX
+        .sets = 64,
+
+        // CPUID 0x4.0x0.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 48 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l1i_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x1.EAX
+        .type = INSTRUCTION_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x1.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 16,
+
+        // CPUID 0x4.0x1.ECX
+        .sets = 64,
+
+        // CPUID 0x4.0x1.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 64 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l2_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x2.EAX
+        .type = UNIFIED_CACHE,
+        .level = 2,
+        .self_init = true,
+
+        // CPUID 0x4.0x2.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 16,
+
+        // CPUID 0x4.0x2.ECX
+        .sets = 2048,
+
+        // CPUID 0x4.0x2.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 2 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l3_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x3.EAX
+        .type = UNIFIED_CACHE,
+        .level = 3,
+        .self_init = true,
+
+        // CPUID 0x4.0x3.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 16,
+
+        // CPUID 0x4.0x3.ECX
+        .sets = 294912,
+
+        // CPUID 0x4.0x3.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = true,
+
+        .size = 288 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_SOCKET,
+    },
+};
+
 static const CPUCaches xeon_srf_cache_info = {
     .l1d_cache = &(CPUCacheInfo) {
         // CPUID 0x4.0x0.EAX
@@ -4517,6 +4608,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                     { /* end of list */ }
                 }
             },
+            {
+                .version = 3,
+                .note = "with gnr-sp cache model",
+                .cache_info = &xeon_gnr_cache_info,
+            },
             { /* end of list */ },
         },
     },
-- 
2.34.1

[RFC 05/10] i386/cpu: Introduce cache model for SapphireRapids

[Zhao Liu]

Add the cache model to SapphireRapids (v4) to better emulate its
environment.

The cache model is based on SapphireRapids-SP (Scalable Performance):

      --- cache 0 ---
      cache type                         = data cache (1)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0xc (12)
      number of sets                     = 0x40 (64)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 64
      (size synth)                       = 49152 (48 KB)
      --- cache 1 ---
      cache type                         = instruction cache (2)
      cache level                        = 0x1 (1)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x8 (8)
      number of sets                     = 0x40 (64)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 64
      (size synth)                       = 32768 (32 KB)
      --- cache 2 ---
      cache type                         = unified cache (3)
      cache level                        = 0x2 (2)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x1 (1)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0x10 (16)
      number of sets                     = 0x800 (2048)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = false
      number of sets (s)                 = 2048
      (size synth)                       = 2097152 (2 MB)
      --- cache 3 ---
      cache type                         = unified cache (3)
      cache level                        = 0x3 (3)
      self-initializing cache level      = true
      fully associative cache            = false
      maximum IDs for CPUs sharing cache = 0x7f (127)
      maximum IDs for cores in pkg       = 0x3f (63)
      system coherency line size         = 0x40 (64)
      physical line partitions           = 0x1 (1)
      ways of associativity              = 0xf (15)
      number of sets                     = 0x10000 (65536)
      WBINVD/INVD acts on lower caches   = false
      inclusive to lower caches          = false
      complex cache indexing             = true
      number of sets (s)                 = 65536
      (size synth)                       = 62914560 (60 MB)
      --- cache 4 ---
      cache type                         = no more caches (0)

Suggested-by: Tejus GK <tejus.gk@nutanix.com>
Suggested-by: Jason Zeng <jason.zeng@intel.com>
Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 00e4a8372c28..d90e048d48f2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -2453,6 +2453,97 @@ static const CPUCaches epyc_genoa_cache_info = {
     },
 };
 
+static const CPUCaches xeon_spr_cache_info = {
+    .l1d_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x0.EAX
+        .type = DATA_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x0.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 12,
+
+        // CPUID 0x4.0x0.ECX
+        .sets = 64,
+
+        // CPUID 0x4.0x0.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 48 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l1i_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x1.EAX
+        .type = INSTRUCTION_CACHE,
+        .level = 1,
+        .self_init = true,
+
+        // CPUID 0x4.0x1.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 8,
+
+        // CPUID 0x4.0x1.ECX
+        .sets = 64,
+
+        // CPUID 0x4.0x1.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 32 * KiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l2_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x2.EAX
+        .type = UNIFIED_CACHE,
+        .level = 2,
+        .self_init = true,
+
+        // CPUID 0x4.0x2.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 16,
+
+        // CPUID 0x4.0x2.ECX
+        .sets = 2048,
+
+        // CPUID 0x4.0x2.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = false,
+
+        .size = 2 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
+    },
+    .l3_cache = &(CPUCacheInfo) {
+        // CPUID 0x4.0x3.EAX
+        .type = UNIFIED_CACHE,
+        .level = 3,
+        .self_init = true,
+
+        // CPUID 0x4.0x3.EBX
+        .line_size = 64,
+        .partitions = 1,
+        .associativity = 15,
+
+        // CPUID 0x4.0x3.ECX
+        .sets = 65536,
+
+        // CPUID 0x4.0x3.EDX
+        .no_invd_sharing = false,
+        .inclusive = false,
+        .complex_indexing = true,
+
+        .size = 60 * MiB,
+        .share_level = CPU_TOPOLOGY_LEVEL_SOCKET,
+    },
+};
+
 static const CPUCaches xeon_gnr_cache_info = {
     .l1d_cache = &(CPUCacheInfo) {
         // CPUID 0x4.0x0.EAX
@@ -4455,6 +4546,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
                     { /* end of list */ }
                 }
             },
+            {
+                .version = 4,
+                .note = "with spr-sp cache model",
+                .cache_info = &xeon_spr_cache_info,
+            },
             { /* end of list */ }
         }
     },
-- 
2.34.1

Re: [RFC 05/10] i386/cpu: Introduce cache model for SapphireRapids

[Tejus GK]

On 23/04/25 5:16 PM, Zhao Liu wrote:
> !-------------------------------------------------------------------|
>    CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> Add the cache model to SapphireRapids (v4) to better emulate its
> environment.
> 
> The cache model is based on SapphireRapids-SP (Scalable Performance):
> 
>        --- cache 0 ---
>        cache type                         = data cache (1)
>        cache level                        = 0x1 (1)
>        self-initializing cache level      = true
>        fully associative cache            = false
>        maximum IDs for CPUs sharing cache = 0x1 (1)
>        maximum IDs for cores in pkg       = 0x3f (63)
>        system coherency line size         = 0x40 (64)
>        physical line partitions           = 0x1 (1)
>        ways of associativity              = 0xc (12)
>        number of sets                     = 0x40 (64)
>        WBINVD/INVD acts on lower caches   = false
>        inclusive to lower caches          = false
>        complex cache indexing             = false
>        number of sets (s)                 = 64
>        (size synth)                       = 49152 (48 KB)
>        --- cache 1 ---
>        cache type                         = instruction cache (2)
>        cache level                        = 0x1 (1)
>        self-initializing cache level      = true
>        fully associative cache            = false
>        maximum IDs for CPUs sharing cache = 0x1 (1)
>        maximum IDs for cores in pkg       = 0x3f (63)
>        system coherency line size         = 0x40 (64)
>        physical line partitions           = 0x1 (1)
>        ways of associativity              = 0x8 (8)
>        number of sets                     = 0x40 (64)
>        WBINVD/INVD acts on lower caches   = false
>        inclusive to lower caches          = false
>        complex cache indexing             = false
>        number of sets (s)                 = 64
>        (size synth)                       = 32768 (32 KB)
>        --- cache 2 ---
>        cache type                         = unified cache (3)
>        cache level                        = 0x2 (2)
>        self-initializing cache level      = true
>        fully associative cache            = false
>        maximum IDs for CPUs sharing cache = 0x1 (1)
>        maximum IDs for cores in pkg       = 0x3f (63)
>        system coherency line size         = 0x40 (64)
>        physical line partitions           = 0x1 (1)
>        ways of associativity              = 0x10 (16)
>        number of sets                     = 0x800 (2048)
>        WBINVD/INVD acts on lower caches   = false
>        inclusive to lower caches          = false
>        complex cache indexing             = false
>        number of sets (s)                 = 2048
>        (size synth)                       = 2097152 (2 MB)
>        --- cache 3 ---
>        cache type                         = unified cache (3)
>        cache level                        = 0x3 (3)
>        self-initializing cache level      = true
>        fully associative cache            = false
>        maximum IDs for CPUs sharing cache = 0x7f (127)
>        maximum IDs for cores in pkg       = 0x3f (63)
>        system coherency line size         = 0x40 (64)
>        physical line partitions           = 0x1 (1)
>        ways of associativity              = 0xf (15)
>        number of sets                     = 0x10000 (65536)
>        WBINVD/INVD acts on lower caches   = false
>        inclusive to lower caches          = false
>        complex cache indexing             = true
>        number of sets (s)                 = 65536
>        (size synth)                       = 62914560 (60 MB)
>        --- cache 4 ---
>        cache type                         = no more caches (0)
> 
> Suggested-by: Tejus GK <tejus.gk@nutanix.com>
> Suggested-by: Jason Zeng <jason.zeng@intel.com>
> Suggested-by: "Daniel P . Berrangé" <berrange@redhat.com>
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
>   target/i386/cpu.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 96 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 00e4a8372c28..d90e048d48f2 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2453,6 +2453,97 @@ static const CPUCaches epyc_genoa_cache_info = {
>       },
>   };
>   
> +static const CPUCaches xeon_spr_cache_info = {
> +    .l1d_cache = &(CPUCacheInfo) {
> +        // CPUID 0x4.0x0.EAX
> +        .type = DATA_CACHE,
> +        .level = 1,
> +        .self_init = true,
> +
> +        // CPUID 0x4.0x0.EBX
> +        .line_size = 64,
> +        .partitions = 1,
> +        .associativity = 12,
> +
> +        // CPUID 0x4.0x0.ECX
> +        .sets = 64,
> +
> +        // CPUID 0x4.0x0.EDX
> +        .no_invd_sharing = false,
> +        .inclusive = false,
> +        .complex_indexing = false,
> +
> +        .size = 48 * KiB,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l1i_cache = &(CPUCacheInfo) {
> +        // CPUID 0x4.0x1.EAX
> +        .type = INSTRUCTION_CACHE,
> +        .level = 1,
> +        .self_init = true,
> +
> +        // CPUID 0x4.0x1.EBX
> +        .line_size = 64,
> +        .partitions = 1,
> +        .associativity = 8,
> +
> +        // CPUID 0x4.0x1.ECX
> +        .sets = 64,
> +
> +        // CPUID 0x4.0x1.EDX
> +        .no_invd_sharing = false,
> +        .inclusive = false,
> +        .complex_indexing = false,
> +
> +        .size = 32 * KiB,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l2_cache = &(CPUCacheInfo) {
> +        // CPUID 0x4.0x2.EAX
> +        .type = UNIFIED_CACHE,
> +        .level = 2,
> +        .self_init = true,
> +
> +        // CPUID 0x4.0x2.EBX
> +        .line_size = 64,
> +        .partitions = 1,
> +        .associativity = 16,
> +
> +        // CPUID 0x4.0x2.ECX
> +        .sets = 2048,
> +
> +        // CPUID 0x4.0x2.EDX
> +        .no_invd_sharing = false,
> +        .inclusive = false,
> +        .complex_indexing = false,
> +
> +        .size = 2 * MiB,
> +        .share_level = CPU_TOPOLOGY_LEVEL_CORE,
> +    },
> +    .l3_cache = &(CPUCacheInfo) {
> +        // CPUID 0x4.0x3.EAX
> +        .type = UNIFIED_CACHE,
> +        .level = 3,
> +        .self_init = true,
> +
> +        // CPUID 0x4.0x3.EBX
> +        .line_size = 64,
> +        .partitions = 1,
> +        .associativity = 15,
> +
> +        // CPUID 0x4.0x3.ECX
> +        .sets = 65536,
> +
> +        // CPUID 0x4.0x3.EDX
> +        .no_invd_sharing = false,
> +        .inclusive = false,
> +        .complex_indexing = true,
> +
> +        .size = 60 * MiB,
> +        .share_level = CPU_TOPOLOGY_LEVEL_SOCKET,
> +    },
> +};
> +
>   static const CPUCaches xeon_gnr_cache_info = {
>       .l1d_cache = &(CPUCacheInfo) {
>           // CPUID 0x4.0x0.EAX
> @@ -4455,6 +4546,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
>                       { /* end of list */ }
>                   }
>               },
> +            {
> +                .version = 4,
> +                .note = "with spr-sp cache model",
> +                .cache_info = &xeon_spr_cache_info,
> +            },
>               { /* end of list */ }
>           }
>       },


Thank you for this improvement! I see that even within the SPR-SP line 
of Processors, the cache sizes vary across different models. What 
happens for an instance when a processor only has 37.5 MiB of L3 per 
socket, but the CPU Model exposes 60 MiB of L3 to the VM?

regards,
Tejus

Re: [RFC 05/10] i386/cpu: Introduce cache model for SapphireRapids

[Zhao Liu]

Hi Tejus,

> Thank you for this improvement! I see that even within the SPR-SP line of
> Processors, the cache sizes vary across different models. What happens for
> an instance when a processor only has 37.5 MiB of L3 per socket, but the CPU
> Model exposes 60 MiB of L3 to the VM?

AFAIK, the Linux scheduler doesn't take cache size into account, so
generally speaking, I think there's no impat on Linux.

If user space apps don't care about this info, then there's no problem.

However, I've met some cases where certain customers prefer that the
named cpu model also become closer to real silicon (e.g. current cache
size). The advantage of this is that an app that works fine on real
silicon is more likely to run normally in a Guest environment...
Because nobody can ensure that no user space app care about cache
size at all. And it's also unknown if there will be other OSes that
depend on the cache size (although I think it should be fine, after
all, current x86 only supports smp machines).

In contrast, the 0x1f example is more typical. By SDM, 0x1f is only
optional, and if 0x1f is not available, the one should check 0xb.
However, in Mishra's case, his windows only relies on 0x1f, so making
the named CPU model and the real silicon alignable is a better way
of avoiding all sorts of incompatibilities.

Thanks,
Zhao

[RFC 06/10] i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f

[Zhao Liu]

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.

Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
 target/i386/cpu.c     | 4 ++--
 target/i386/cpu.h     | 9 +++++++++
 target/i386/kvm/kvm.c | 2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index d90e048d48f2..e0716dbe5934 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7292,7 +7292,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
         break;
     case 0x1F:
         /* V2 Extended Topology Enumeration Leaf */
-        if (!x86_has_extended_topo(env->avail_cpu_topo)) {
+        if (!x86_has_cpuid_0x1f(cpu)) {
             *eax = *ebx = *ecx = *edx = 0;
             break;
         }
@@ -8178,7 +8178,7 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
          * cpu->vendor_cpuid_only has been unset for compatibility with older
          * machine types.
          */
-        if (x86_has_extended_topo(env->avail_cpu_topo) &&
+        if (x86_has_cpuid_0x1f(cpu) &&
             (IS_INTEL_CPU(env) || !cpu->vendor_cpuid_only)) {
             x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x1F);
         }
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 76f24446a55d..3910b488f775 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2251,6 +2251,9 @@ struct ArchCPU {
     /* Compatibility bits for old machine types: */
     bool enable_cpuid_0xb;
 
+    /* Force to enable cpuid 0x1f */
+    bool enable_cpuid_0x1f;
+
     /* Enable auto level-increase for all CPUID leaves */
     bool full_cpuid_auto_level;
 
@@ -2513,6 +2516,12 @@ void host_cpuid(uint32_t function, uint32_t count,
                 uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx);
 bool cpu_has_x2apic_feature(CPUX86State *env);
 
+static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
+{
+    return cpu->enable_cpuid_0x1f ||
+           x86_has_extended_topo(cpu->env.avail_cpu_topo);
+}
+
 /* helper.c */
 void x86_cpu_set_a20(X86CPU *cpu, int a20_state);
 void cpu_sync_avx_hflag(CPUX86State *env);
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 6c749d4ee812..23b8de308525 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -1863,7 +1863,7 @@ static uint32_t kvm_x86_build_cpuid(CPUX86State *env,
             break;
         }
         case 0x1f:
-            if (!x86_has_extended_topo(env->avail_cpu_topo)) {
+            if (!x86_has_cpuid_0x1f(env_archcpu(env))) {
                 cpuid_i--;
                 break;
             }
-- 
2.34.1

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

[Igor Mammedov]

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?

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

and also enable_ is not right here, the leaf is enabled when
topology requires it.
perhaps s/enable_/force_/
 
> 
> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
>  target/i386/cpu.c     | 4 ++--
>  target/i386/cpu.h     | 9 +++++++++
>  target/i386/kvm/kvm.c | 2 +-
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index d90e048d48f2..e0716dbe5934 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -7292,7 +7292,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
>          break;
>      case 0x1F:
>          /* V2 Extended Topology Enumeration Leaf */
> -        if (!x86_has_extended_topo(env->avail_cpu_topo)) {
> +        if (!x86_has_cpuid_0x1f(cpu)) {
>              *eax = *ebx = *ecx = *edx = 0;
>              break;
>          }
> @@ -8178,7 +8178,7 @@ void x86_cpu_expand_features(X86CPU *cpu, Error **errp)
>           * cpu->vendor_cpuid_only has been unset for compatibility with older
>           * machine types.
>           */
> -        if (x86_has_extended_topo(env->avail_cpu_topo) &&
> +        if (x86_has_cpuid_0x1f(cpu) &&
>              (IS_INTEL_CPU(env) || !cpu->vendor_cpuid_only)) {
>              x86_cpu_adjust_level(cpu, &env->cpuid_min_level, 0x1F);
>          }
> diff --git a/target/i386/cpu.h b/target/i386/cpu.h
> index 76f24446a55d..3910b488f775 100644
> --- a/target/i386/cpu.h
> +++ b/target/i386/cpu.h
> @@ -2251,6 +2251,9 @@ struct ArchCPU {
>      /* Compatibility bits for old machine types: */
>      bool enable_cpuid_0xb;
>  
> +    /* Force to enable cpuid 0x1f */
> +    bool enable_cpuid_0x1f;
> +
>      /* Enable auto level-increase for all CPUID leaves */
>      bool full_cpuid_auto_level;
>  
> @@ -2513,6 +2516,12 @@ void host_cpuid(uint32_t function, uint32_t count,
>                  uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx);
>  bool cpu_has_x2apic_feature(CPUX86State *env);
>  
> +static inline bool x86_has_cpuid_0x1f(X86CPU *cpu)
> +{
> +    return cpu->enable_cpuid_0x1f ||
> +           x86_has_extended_topo(cpu->env.avail_cpu_topo);
> +}
> +
>  /* helper.c */
>  void x86_cpu_set_a20(X86CPU *cpu, int a20_state);
>  void cpu_sync_avx_hflag(CPUX86State *env);
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index 6c749d4ee812..23b8de308525 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -1863,7 +1863,7 @@ static uint32_t kvm_x86_build_cpuid(CPUX86State *env,
>              break;
>          }
>          case 0x1f:
> -            if (!x86_has_extended_topo(env->avail_cpu_topo)) {
> +            if (!x86_has_cpuid_0x1f(env_archcpu(env))) {
>                  cpuid_i--;
>                  break;
>              }

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

[Zhao Liu]

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.

Regards,
Zhao

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

[Xiaoyao Li]

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
> 

[RFC 07/10] i386/cpu: Add a "cpuid-0x1f" property

[Zhao Liu]

From: Manish Mishra <manish.mishra@nutanix.com>

Add a "cpuid-0x1f" property so that CPU models can enable it and have
0x1f CPUID leaf natually as the Host CPU.

The advantage is that when the CPU model's cache model is already
consistent with the Host CPU, for example, SRF defaults to l2 per
module & l3 per package, 0x1f can better help users identify the
topology in the VM.

Adding 0x1f for specific CPU models should not cause any trouble in
principle. This property is only enabled for CPU models that already
have 0x1f leaf on the Host, so software that originally runs normally on
the Host won't encounter issues in the Guest with corresponding CPU
model. Conversely, some software that relies on checking 0x1f might
experience problems in the Guest due to the lack of 0x1f [*]. In
summary, adding 0x1f is also intended to further emulate the Host CPU
environment. Therefore, the "x-" prefix is not added to this property.

[*]: https://lore.kernel.org/qemu-devel/PH0PR02MB738410511BF51B12DB09BE6CF6AC2@PH0PR02MB7384.namprd02.prod.outlook.com/

Co-authored-by: Xiaoyao Li <xiaoyao.li@intel.com>
(Missing signed-off from Manish & Xiaoyao)
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
Note:
  This patch integrates the idea from 2 previous posted patches (ordered
by post time)[1] [2]. Although the target cases are not exactly the same
as this patch, add the authorship of previous authors.

[1]: From Manish: https://lore.kernel.org/qemu-devel/20240722101859.47408-1-manish.mishra@nutanix.com/
[2]: From Xiaoyao: https://lore.kernel.org/qemu-devel/20240813033145.279307-1-xiaoyao.li@intel.com/
---
 target/i386/cpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e0716dbe5934..26dc5b6a6a8c 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -9195,6 +9195,7 @@ static const Property x86_cpu_properties[] = {
     DEFINE_PROP_BOOL("x-intel-pt-auto-level", X86CPU, intel_pt_auto_level,
                      true),
     DEFINE_PROP_BOOL("x-l1-cache-per-thread", X86CPU, l1_cache_per_core, true),
+    DEFINE_PROP_BOOL("cpuid-0x1f", X86CPU, enable_cpuid_0x1f, false),
 };
 
 #ifndef CONFIG_USER_ONLY
-- 
2.34.1

[RFC 08/10] i386/cpu: Enable 0x1f leaf for SierraForest by default

[Zhao Liu]

Host SierraForest CPU has 0x1f leaf by default, so that enable it for
Guest CPU by default as well.

Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 26dc5b6a6a8c..2a518b68e67a 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4856,8 +4856,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
             },
             {
                 .version = 3,
-                .note = "with srf-sp cache model",
+                .note = "with srf-sp cache model and 0x1f leaf",
                 .cache_info = &xeon_srf_cache_info,
+                .props = (PropValue[]) {
+                    { "cpuid-0x1f", "on" },
+                }
             },
             { /* end of list */ },
         },
-- 
2.34.1

[RFC 09/10] i386/cpu: Enable 0x1f leaf for GraniteRapids by default

[Zhao Liu]

Host GraniteRapids CPU has 0x1f leaf by default, so that enable it for
Guest CPU by default as well.

Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 2a518b68e67a..38b330aaed4f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4706,8 +4706,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
             },
             {
                 .version = 3,
-                .note = "with gnr-sp cache model",
+                .note = "with gnr-sp cache model and 0x1f leaf",
                 .cache_info = &xeon_gnr_cache_info,
+                .props = (PropValue[]) {
+                    { "cpuid-0x1f", "on" },
+                }
             },
             { /* end of list */ },
         },
-- 
2.34.1

[RFC 10/10] i386/cpu: Enable 0x1f leaf for SapphireRapids by default

[Zhao Liu]

Host SapphireRapids CPU has 0x1f leaf by default, so that enable it for
Guest CPU by default as well.

Suggested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 target/i386/cpu.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 38b330aaed4f..5573a9fd6c61 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -4548,8 +4548,11 @@ static const X86CPUDefinition builtin_x86_defs[] = {
             },
             {
                 .version = 4,
-                .note = "with spr-sp cache model",
+                .note = "with spr-sp cache model and 0x1f leaf",
                 .cache_info = &xeon_spr_cache_info,
+                .props = (PropValue[]) {
+                    { "cpuid-0x1f", "on" },
+                }
             },
             { /* end of list */ }
         }
-- 
2.34.1

Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[Zhao Liu]

On Wed, Apr 23, 2025 at 07:46:52PM +0800, Zhao Liu wrote:
> Date: Wed, 23 Apr 2025 19:46:52 +0800
> From: Zhao Liu <zhao1.liu@intel.com>
> Subject: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo
>  CPUID enhencement
> X-Mailer: git-send-email 2.34.1
> 
> Hi all,
> 
> (Since patches 1 and 2 involve changes to x86 vendors other than Intel,
> I have also cc'd friends from AMD and Zhaoxin.)
> 
> These are the ones I was going to clean up a long time ago:
>  * Fixup CPUID 0x80000005 & 0x80000006 for Intel (and Zhaoxin now).
>  * Add cache model for Intel CPUs.
>  * Enable 0x1f CPUID leaf for specific Intel CPUs, which already have
>    this leaf on host by default.
> 
> Overall, the enhancements to the Intel CPU models are still based on
> feedback received over time, for a long time...
> 
> I'll introduce my changes one by one in the order of importance as I
> see it. (The doc update is missing in this version.)
> 
> 
> Intel Cache Model
> =================
> 
> AMD has supports cache model for a long time. And this feature strats
> from the Eduardo's idea [1].
> 
> Unfortunately, Intel does not support this, and I have received some
> feedback (from Tejus on mail list [2] and kvm forum, and from Jason).

I need to add more background:

the legacy "host-cache-info" is becoming failing... On SRF, we have
observed that it cannot accurately identify cache topology, so we have
to use "smp-cache" to set the cache topology.

However, once "host-cache-info" is disabled, we lose the cache info
that matches the real silicon... Therefore, we can only add the cache
model for the named CPU model.

Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[Ewan Hai]

On 4/23/25 7:46 PM, Zhao Liu wrote:
> Hi all,
> 
> (Since patches 1 and 2 involve changes to x86 vendors other than Intel,
> I have also cc'd friends from AMD and Zhaoxin.)
> 
> These are the ones I was going to clean up a long time ago:
>   * Fixup CPUID 0x80000005 & 0x80000006 for Intel (and Zhaoxin now).
>   * Add cache model for Intel CPUs.
>   * Enable 0x1f CPUID leaf for specific Intel CPUs, which already have
>     this leaf on host by default.

If you run into vendor specific branches while refactoring the topology-related 
code, please feel free to treat Intel and Zhaoxin as one class. For every 
topology CPUID leaf(0x0B, 0x1F, ...) so far, Zhaoxin has followed the Intel SDM 
definition exactly.

Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[Zhao Liu]

On Mon, May 26, 2025 at 06:52:41PM +0800, Ewan Hai wrote:
> Date: Mon, 26 May 2025 18:52:41 +0800
> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
> Subject: Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model &
>  topo CPUID enhencement
> 
> 
> 
> On 4/23/25 7:46 PM, Zhao Liu wrote:
> > Hi all,
> > 
> > (Since patches 1 and 2 involve changes to x86 vendors other than Intel,
> > I have also cc'd friends from AMD and Zhaoxin.)
> > 
> > These are the ones I was going to clean up a long time ago:
> >   * Fixup CPUID 0x80000005 & 0x80000006 for Intel (and Zhaoxin now).
> >   * Add cache model for Intel CPUs.
> >   * Enable 0x1f CPUID leaf for specific Intel CPUs, which already have
> >     this leaf on host by default.
> 
> If you run into vendor specific branches while refactoring the
> topology-related code, please feel free to treat Intel and Zhaoxin as one
> class. For every topology CPUID leaf(0x0B, 0x1F, ...) so far, Zhaoxin has
> followed the Intel SDM definition exactly.

Thank you for your confirmation. I'll post v2 soon (If things go well,
it'll be in the next two weeks. :-) )

Regards,
Zhao

Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement

[Ewan Hai]

On 5/27/25 5:19 PM, Zhao Liu wrote:
> 
> On Mon, May 26, 2025 at 06:52:41PM +0800, Ewan Hai wrote:
>> Date: Mon, 26 May 2025 18:52:41 +0800
>> From: Ewan Hai <ewanhai-oc@zhaoxin.com>
>> Subject: Re: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model &
>>   topo CPUID enhencement
>>
>>
>>
>> On 4/23/25 7:46 PM, Zhao Liu wrote:
>>> Hi all,
>>>
>>> (Since patches 1 and 2 involve changes to x86 vendors other than Intel,
>>> I have also cc'd friends from AMD and Zhaoxin.)
>>>
>>> These are the ones I was going to clean up a long time ago:
>>>    * Fixup CPUID 0x80000005 & 0x80000006 for Intel (and Zhaoxin now).
>>>    * Add cache model for Intel CPUs.
>>>    * Enable 0x1f CPUID leaf for specific Intel CPUs, which already have
>>>      this leaf on host by default.
>>
>> If you run into vendor specific branches while refactoring the
>> topology-related code, please feel free to treat Intel and Zhaoxin as one
>> class. For every topology CPUID leaf(0x0B, 0x1F, ...) so far, Zhaoxin has
>> followed the Intel SDM definition exactly.
> 
> Thank you for your confirmation. I'll post v2 soon (If things go well,
> it'll be in the next two weeks. :-) )

No rush, everyone is busy, maintainers especially so. Just handle it whenever it 
best fits your schedule.