From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Marek Marczykowski <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init
Date: Mon, 23 Mar 2026 12:43:35 +0100 [thread overview]
Message-ID: <acEnZw1AS5F5G0y4@macbook.local> (raw)
In-Reply-To: <72f9adbe-6dab-4070-be20-3f40f3a37c2b@suse.com>
On Mon, Mar 23, 2026 at 12:38:48PM +0100, Jan Beulich wrote:
> On 23.03.2026 12:16, Roger Pau Monné wrote:
> > On Wed, Mar 04, 2026 at 02:39:01PM +0100, Jan Beulich wrote:
> >> MCE init for APs was broken when CPU feature re-checking was added. MTRR
> >> (re)init for the BSP looks to never have been there on the resume path.
> >
> > I'm not sure the statement about MTRR init is correct, AFAICT
> > mtrr_aps_sync_end() will also re-init the MTRRs on the BSP, and hence
> > the added mtrr_ap_init() seems to duplicate what's already done in
> > mtrr_aps_sync_end().
>
> Hmm, right you are. Had I been asked, I would have confirmed that I checked
> the code past the "enable_cpu" label, but clearly I must not have, or I was
> blind at that time. Let me strip that out.
>
> >> --- a/xen/arch/x86/cpu/common.c
> >> +++ b/xen/arch/x86/cpu/common.c
> >> @@ -642,16 +642,21 @@ void identify_cpu(struct cpuinfo_x86 *c)
> >> smp_processor_id());
> >> }
> >>
> >> - if (system_state == SYS_STATE_resume)
> >> - return;
> >> + if (system_state == SYS_STATE_resume) {
> >> + unsigned int cpu = smp_processor_id();
> >>
> >> + if (cpu)
> >> + mcheck_init(&cpu_data[cpu], false);
> >> + else /* Yes, the BSP needs to use the AP function here. */
> >> + mtrr_ap_init();
> >
> > For symmetry with the BSP path, is it really needed to init MCE so
> > early for the BSP by calling it directly in enter_state(), or could it
> > also be done here?
>
> To be honest, I would put the question the other way around: Is it really
> okay to do it this late for APs (during boot also for the BSP [1])? Iirc
> an #MC prior to mcheck_init() is going to be deadly to the system. Moving
> it earlier may, however, be a more intrusive change.
We might want to at least add a note to document this asymmetric
initialization between the BSP and the APs at least?
I would be perfectly happy with moving this earlier, and it needs to
be consistent between the APs and the BSP.
Thanks, Roger.
prev parent reply other threads:[~2026-03-23 11:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-04 13:39 [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init Jan Beulich
2026-03-04 14:36 ` Marek Marczykowski
2026-03-04 14:47 ` Jan Beulich
2026-03-04 15:00 ` Marek Marczykowski
2026-03-23 11:21 ` Jan Beulich
2026-03-23 11:26 ` Marek Marczykowski
2026-03-23 11:16 ` Roger Pau Monné
2026-03-23 11:38 ` Jan Beulich
2026-03-23 11:43 ` Roger Pau Monné [this message]
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=acEnZw1AS5F5G0y4@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=marmarek@invisiblethingslab.com \
--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.