kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>
Cc: Babu Moger <babu.moger@amd.com>,
	Ewan Hai <ewanhai-oc@zhaoxin.com>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	Tejus GK <tejus.gk@nutanix.com>,
	Jason Zeng <jason.zeng@intel.com>,
	Manish Mishra <manish.mishra@nutanix.com>,
	Tao Su <tao1.su@intel.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Zhao Liu <zhao1.liu@intel.com>
Subject: [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement
Date: Wed, 23 Apr 2025 19:46:52 +0800	[thread overview]
Message-ID: <20250423114702.1529340-1-zhao1.liu@intel.com> (raw)

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


             reply	other threads:[~2025-04-23 11:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 11:46 Zhao Liu [this message]
2025-04-23 11:46 ` [RFC 01/10] i386/cpu: Mark CPUID[0x80000005] as reserved for Intel Zhao Liu
2025-04-23 13:05   ` Xiaoyao Li
2025-04-24  2:52     ` Zhao Liu
2025-04-24 13:44   ` Ewan Hai
2025-04-25  9:39     ` Zhao Liu
2025-05-26  8:35   ` Ewan Hai
2025-05-27  9:15     ` Zhao Liu
2025-05-27  9:56       ` Ewan Hai
2025-06-24  7:22         ` Zhao Liu
2025-06-24 11:04           ` Ewan Hai
2025-06-25  3:03             ` Zhao Liu
2025-06-25  2:54               ` Ewan Hai
2025-06-25  9:19     ` Zhao Liu
2025-06-25 10:05       ` Ewan Hai
2025-04-23 11:46 ` [RFC 02/10] i386/cpu: Fix CPUID[0x80000006] for Intel CPU Zhao Liu
2025-04-23 11:46 ` [RFC 03/10] i386/cpu: Introduce cache model for SierraForest Zhao Liu
2025-04-23 11:46 ` [RFC 04/10] i386/cpu: Introduce cache model for GraniteRapids Zhao Liu
2025-04-23 11:46 ` [RFC 05/10] i386/cpu: Introduce cache model for SapphireRapids Zhao Liu
2025-04-24  4:54   ` Tejus GK
2025-04-24  6:53     ` Zhao Liu
2025-04-23 11:46 ` [RFC 06/10] i386/cpu: Introduce enable_cpuid_0x1f to force exposing CPUID 0x1f Zhao Liu
2025-05-13 12:45   ` Igor Mammedov
2025-05-14 15:23     ` Zhao Liu
2025-05-15  6:43       ` Xiaoyao Li
2025-04-23 11:46 ` [RFC 07/10] i386/cpu: Add a "cpuid-0x1f" property Zhao Liu
2025-04-23 11:47 ` [RFC 08/10] i386/cpu: Enable 0x1f leaf for SierraForest by default Zhao Liu
2025-04-23 11:47 ` [RFC 09/10] i386/cpu: Enable 0x1f leaf for GraniteRapids " Zhao Liu
2025-04-23 11:47 ` [RFC 10/10] i386/cpu: Enable 0x1f leaf for SapphireRapids " Zhao Liu
2025-04-24  6:57 ` [RFC 00/10] i386/cpu: Cache CPUID fixup, Intel cache model & topo CPUID enhencement Zhao Liu
2025-05-26 10:52 ` Ewan Hai
2025-05-27  9:19   ` Zhao Liu
2025-05-27  9:58     ` Ewan Hai

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20250423114702.1529340-1-zhao1.liu@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=babu.moger@amd.com \
    --cc=berrange@redhat.com \
    --cc=ewanhai-oc@zhaoxin.com \
    --cc=imammedo@redhat.com \
    --cc=jason.zeng@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=manish.mishra@nutanix.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tao1.su@intel.com \
    --cc=tejus.gk@nutanix.com \
    --cc=xiaoyao.li@intel.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).