From: Zhao Liu <zhao1.liu@intel.com>
To: Shivansh Dhiman <shivansh.dhiman@amd.com>
Cc: pbonzini@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org,
qemu-devel@nongnu.org, seanjc@google.com, santosh.shukla@amd.com,
nikunj.dadhania@amd.com, ravi.bangoria@amd.com,
babu.moger@amd.com, K Prateek Nayak <kprateek.nayak@amd.com>
Subject: Re: [PATCH 1/5] i386: Implement CPUID 0x80000026
Date: Mon, 12 Jan 2026 16:01:23 +0800 [thread overview]
Message-ID: <aWSqUylwHmhIeBjq@intel.com> (raw)
In-Reply-To: <df23391a-599a-495b-a1b2-ed548215e2c5@amd.com>
> >> The current kernel doesn't have sensitivity to a level between L3 boundary and
> >> socket. Also, most production systems in current AMD CPU landscape have CCD=CCX.
> >> Only a handful of models feature CCD=2CCX, so this isn't an immediate pressing need.
> >>
> >> In QEMU's terminology, socket represents an actual socket and die represents the
> >> L3 cache boundary. There is no intermediate level between them. Looking ahead,
> >> when more granular topology information (like CCD) becomes necessary for VMs,
> >> introducing a "diegroup" level would be the logical approach. This level would
> >> fit naturally between die and socket, as its role cannot be fulfilled by
> >> existing topology levels.
> >
> > With your nice clarification, I think this problem has become a bit easier.
> >
> > In fact, we can consider that CCD=CCX=die is currently the default
> > assumption in QEMU. When future implementations require distinguishing between
> > these CCD/CCX concepts, we can simply introduce an additional "smp.tiles" and
> > map CCX to it. This may need a documentation or a compatibility option, but I
> > believe these extra efforts are worthwhile.
> >
> > And "smp.tiles" means "how many tiles in a die", so I feel it's perfect
> > to describe CCX.
>
> That indeed looks like a cleaner solution. However, I'm concerned about
> retaining compatibility with existing "dies". But yeah, that's a task for a
> later time.
Yes, it may be necessary to address some compatibility issues. But I think
this way could align with the topology mapping of the Linux kernel as much
as possible.
Thanks,
Zhao
next prev parent reply other threads:[~2026-01-12 7:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 8:34 [PATCH 0/5] i386: Add support for CPUID 0x80000026 and Bus Lock Detect Shivansh Dhiman
2025-11-21 8:34 ` [PATCH 1/5] i386: Implement CPUID 0x80000026 Shivansh Dhiman
2026-01-07 7:25 ` Zhao Liu
2026-01-08 10:33 ` Shivansh Dhiman
2026-01-09 9:03 ` Zhao Liu
2026-01-09 11:41 ` Shivansh Dhiman
2026-01-12 8:01 ` Zhao Liu [this message]
2026-02-04 6:43 ` Shivansh Dhiman
2025-11-21 8:34 ` [PATCH 2/5] i386: Add CPU property x-force-cpuid-0x80000026 Shivansh Dhiman
2026-01-07 7:47 ` Zhao Liu
2026-01-09 9:00 ` Shivansh Dhiman
2026-01-12 7:57 ` Zhao Liu
2026-02-04 6:42 ` Shivansh Dhiman
2025-11-21 8:34 ` [PATCH 3/5] i386: Enable CPUID 80000026 for EPYC-Genoa/Turin vCPU Shivansh Dhiman
2026-01-07 7:47 ` Zhao Liu
2025-11-21 8:34 ` [PATCH 4/5] i386: Add Bus Lock Detect support Shivansh Dhiman
2026-02-04 9:02 ` Shivansh Dhiman
2025-11-21 8:34 ` [PATCH 5/5] i386: Add Bus Lock Detect support for EPYC-Turin-v2 model Shivansh Dhiman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWSqUylwHmhIeBjq@intel.com \
--to=zhao1.liu@intel.com \
--cc=babu.moger@amd.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ravi.bangoria@amd.com \
--cc=santosh.shukla@amd.com \
--cc=seanjc@google.com \
--cc=shivansh.dhiman@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.