From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] x86/intel: ensure Global Performance Counter Control is setup correctly
Date: Thu, 11 Jan 2024 11:40:12 +0100 [thread overview]
Message-ID: <ZZ_FjFa9mILtDZgv@macbook> (raw)
In-Reply-To: <3428928a-42d0-4e4b-9607-c184968c309d@suse.com>
On Thu, Jan 11, 2024 at 11:11:07AM +0100, Jan Beulich wrote:
> On 11.01.2024 10:08, Roger Pau Monne wrote:
> > When Architectural Performance Monitoring is available, the PERF_GLOBAL_CTRL
> > MSR contains per-counter enable bits that is ANDed with the enable bit in the
> > counter EVNTSEL MSR in order for a PMC counter to be enabled.
> >
> > So far the watchdog code seems to have relied on the PERF_GLOBAL_CTRL enable
> > bits being set by default, but at least on some Intel Sapphire and Emerald
> > Rapids this is no longer the case, and Xen reports:
> >
> > Testing NMI watchdog on all CPUs: 0 40 stuck
> >
> > The first CPU on each package is started with PERF_GLOBAL_CTRL zeroed, so PMC0
> > doesn't start counting when the enable bit in EVNTSEL0 is set, due to the
> > relevant enable bit in PERF_GLOBAL_CTRL not being set.
> >
> > Check and adjust PERF_GLOBAL_CTRL during CPU initialization so that all the
> > general-purpose PMCs are enabled. Doing so brings the state of the package-BSP
> > PERF_GLOBAL_CTRL in line with the rest of the CPUs on the system.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Changes since v1:
> > - Do the adjustment of PERF_GLOBAL_CTRL even if the watchdog is not used, and
> > enable all counters.
> > ---
> > Unsure whether printing a warning if the value of PERF_GLOBAL_CTRL is not
> > correct is of any value, hence I haven't added it.
> > ---
> > xen/arch/x86/cpu/intel.c | 18 +++++++++++++++++-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> > index dfee64689ffe..40d3eb0e18a7 100644
> > --- a/xen/arch/x86/cpu/intel.c
> > +++ b/xen/arch/x86/cpu/intel.c
> > @@ -533,9 +533,25 @@ static void cf_check init_intel(struct cpuinfo_x86 *c)
> > init_intel_cacheinfo(c);
> > if (c->cpuid_level > 9) {
> > unsigned eax = cpuid_eax(10);
> > + unsigned int cnt = (uint8_t)(eax >> 8);
> > +
> > /* Check for version and the number of counters */
> > - if ((eax & 0xff) && (((eax>>8) & 0xff) > 1))
> > + if ((eax & 0xff) && (cnt > 1) && (cnt <= 32)) {
>
> I may not have looked closely enough, but I didn't find the limit of
> 32 being stated anywhere.
Hm, my copy of the SDM vol4 states that bits 31:n are the enable bits,
where n is CPUID.0AH: EAX[15:8]. Bits 32, 33 and 34 control the Fixed
PMCs.
> > + uint64_t global_ctrl;
> > + unsigned int cnt_mask = (1UL << cnt) - 1;
>
> Bits 2 + 4 * n have an additional qualification as per SDM vol 4.
Let me update my copy...
Looking at the version from December 2023, I see:
0 EN_PMC0 If CPUID.0AH: EAX[15:8] > 0
1 EN_PMC1 If CPUID.0AH: EAX[15:8] > 1
2 EN_PMC2 If CPUID.0AH: EAX[15:8] > 2
n EN_PMCn If CPUID.0AH: EAX[15:8] > n
31:n+1 Reserved.
And I'm afraid I'm not able to infer this additional qualification of
bits 2 + 4 * n.
Thanks, Roger.
next prev parent reply other threads:[~2024-01-11 10:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 9:08 [PATCH v2] x86/intel: ensure Global Performance Counter Control is setup correctly Roger Pau Monne
2024-01-11 10:00 ` Jan Beulich
2024-01-11 10:32 ` Roger Pau Monné
2024-01-11 10:38 ` Jan Beulich
2024-01-11 10:11 ` Jan Beulich
2024-01-11 10:40 ` Roger Pau Monné [this message]
2024-01-11 11:34 ` Jan Beulich
2024-01-11 12:22 ` Roger Pau Monné
2024-01-11 14:01 ` Jan Beulich
2024-01-11 14:15 ` Roger Pau Monné
2024-01-11 15:52 ` Jan Beulich
2024-01-11 16:53 ` Roger Pau Monné
2024-01-12 7:42 ` Jan Beulich
2024-01-12 10:08 ` Roger Pau Monné
2024-01-12 10:19 ` Jan Beulich
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=ZZ_FjFa9mILtDZgv@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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.