From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Dapeng Mi <dapeng1.mi@linux.intel.com>,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jim Mattson <jmattson@google.com>,
Mingwei Zhang <mizhang@google.com>,
Zide Chen <zide.chen@intel.com>,
Das Sandipan <Sandipan.Das@amd.com>,
Shukla Manali <Manali.Shukla@amd.com>, Yi Lai <yi1.lai@intel.com>,
Dapeng Mi <dapeng1.mi@intel.com>,
dongsheng <dongsheng.x.zhang@intel.com>
Subject: Re: [kvm-unit-tests patch 1/5] x86/pmu: Add helper to detect Intel overcount issues
Date: Tue, 15 Jul 2025 21:27:40 +0800 [thread overview]
Message-ID: <e635c41e-55be-408d-ab43-7875021a9ecc@intel.com> (raw)
In-Reply-To: <20250712174915.196103-2-dapeng1.mi@linux.intel.com>
On 7/13/2025 1:49 AM, Dapeng Mi wrote:
> From: dongsheng <dongsheng.x.zhang@intel.com>
>
> For Intel Atom CPUs, the PMU events "Instruction Retired" or
> "Branch Instruction Retired" may be overcounted for some certain
> instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
> and complex SGX/SMX/CSTATE instructions/flows.
>
> The detailed information can be found in the errata (section SRF7):
> https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
>
> For the Atom platforms before Sierra Forest (including Sierra Forest),
> Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
> be overcounted on these certain instructions, but for Clearwater Forest
> only "Instruction Retired" event is overcounted on these instructions.
>
> So add a helper detect_inst_overcount_flags() to detect whether the
> platform has the overcount issue and the later patches would relax the
> precise count check by leveraging the gotten overcount flags from this
> helper.
>
> Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
> [Rewrite comments and commit message - Dapeng]
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Tested-by: Yi Lai <yi1.lai@intel.com>
> ---
> lib/x86/processor.h | 17 ++++++++++++++++
> x86/pmu.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 64 insertions(+)
>
> diff --git a/lib/x86/processor.h b/lib/x86/processor.h
> index 62f3d578..3f475c21 100644
> --- a/lib/x86/processor.h
> +++ b/lib/x86/processor.h
> @@ -1188,4 +1188,21 @@ static inline bool is_lam_u57_enabled(void)
> return !!(read_cr3() & X86_CR3_LAM_U57);
> }
>
> +static inline u32 x86_family(u32 eax)
> +{
> + u32 x86;
> +
> + x86 = (eax >> 8) & 0xf;
> +
> + if (x86 == 0xf)
> + x86 += (eax >> 20) & 0xff;
> +
> + return x86;
> +}
> +
> +static inline u32 x86_model(u32 eax)
> +{
> + return ((eax >> 12) & 0xf0) | ((eax >> 4) & 0x0f);
> +}
It seems to copy the implementation of kvm selftest.
I need to point it out that it's not correct (because I fixed the
similar issue on QEMU recently).
We cannot count Extended Model ID unconditionally. Intel counts Extended
Model when (base) Family is 0x6 or 0xF, while AMD counts EXtended Model
when (base) Family is 0xF.
You can refer to kernel's x86_model() in arch/x86/lib/cpu.c, while it
optimizes the condition to "family >= 0x6", which seems to have the
assumption that Intel doesn't have processor with family ID from 7 to
0xe and AMD doesn't have processor with family ID from 6 to 0xe.
next prev parent reply other threads:[~2025-07-15 13:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-12 17:49 [kvm-unit-tests patch 0/5] Fix pmu test errors on SRF/CWF Dapeng Mi
2025-07-12 17:49 ` [kvm-unit-tests patch 1/5] x86/pmu: Add helper to detect Intel overcount issues Dapeng Mi
2025-07-15 13:27 ` Xiaoyao Li [this message]
2025-07-16 1:13 ` Mi, Dapeng
2025-07-12 17:49 ` [kvm-unit-tests patch 2/5] x86/pmu: Relax precise count validation for Intel overcounted platforms Dapeng Mi
2025-07-12 17:49 ` [kvm-unit-tests patch 3/5] x86/pmu: Fix incorrect masking of fixed counters Dapeng Mi
2025-07-12 17:49 ` [kvm-unit-tests patch 4/5] x86/pmu: Handle instruction overcount issue in overflow test Dapeng Mi
2025-07-12 17:49 ` [kvm-unit-tests patch 5/5] x86/pmu: Expand "llc references" upper limit for broader compatibility Dapeng Mi
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=e635c41e-55be-408d-ab43-7875021a9ecc@intel.com \
--to=xiaoyao.li@intel.com \
--cc=Manali.Shukla@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=dapeng1.mi@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=dongsheng.x.zhang@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=yi1.lai@intel.com \
--cc=zide.chen@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
all inboxes | Powered by JetHome®