From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, Tony Luck <tony.luck@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org,
Smita.KoralahalliChannabasappa@amd.com,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v5 07/20] x86/mce: Reorder __mcheck_cpu_init_generic() call
Date: Tue, 2 Sep 2025 09:30:15 -0400 [thread overview]
Message-ID: <20250902133015.GA18483@yaz-khff2.amd.com> (raw)
In-Reply-To: <20250901170741.GCaLXS3bUdUPksnMs8@fat_crate.local>
On Mon, Sep 01, 2025 at 07:07:41PM +0200, Borislav Petkov wrote:
> On Mon, Aug 25, 2025 at 05:33:04PM +0000, Yazen Ghannam wrote:
> > Move __mcheck_cpu_init_generic() after __mcheck_cpu_init_prepare_banks()
> > so that MCA is enabled after the first MCA polling event.
> >
> > This brings the MCA init flow closer to what is described in the x86 docs.
> >
> > The AMD PPRs say
> > "The operating system must initialize the MCA_CONFIG registers prior
> > to initialization of the MCA_CTL registers.
> >
> > The MCA_CTL registers must be initialized prior to enabling the error
> > reporting banks in MCG_CTL".
> >
> > However, the Intel SDM "Machine-Check Initialization Pseudocode" says
> > MCG_CTL first then MCi_CTL.
> >
> > But both agree that CR4.MCE should be set last.
> >
> > Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> > ---
> >
> > Notes:
> > Link:
> > https://lore.kernel.org/r/52a37afe-c41b-4f20-bbdc-bddc3ae26260@suse.com
> >
> > v4->v5:
> > * New in v5.
> >
> > arch/x86/kernel/cpu/mce/core.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 0326fbb83adc..9cbf9e8c8060 100644
> > --- a/arch/x86/kernel/cpu/mce/core.c
> > +++ b/arch/x86/kernel/cpu/mce/core.c
> > @@ -2272,9 +2272,9 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)
> >
> > mca_cfg.initialized = 1;
> >
> > - __mcheck_cpu_init_generic();
> > __mcheck_cpu_init_vendor(c);
> > __mcheck_cpu_init_prepare_banks();
> > + __mcheck_cpu_init_generic();
>
> With that flow we have now:
>
> 1. MCA_CTL
> 2. CR4.MCE
> 3. MCG_CTL
>
> So this is nothing like in the commit message above and the MC*_CTL flow is
> not what the SDM suggests and CR4.MCE is not last.
>
> So what's the point even here?
>
The main point is to initialize MCA after polling for leftover errors.
You're right that this change doesn't bring the code in sync with the
docs. I'll work on it more.
Moving CR4.MCE last should be okay, but deciding when to do MCG_CTL
needs some more thought. Maybe we can have an early call for Intel and
a late call for AMD?
Thanks,
Yazen
next prev parent reply other threads:[~2025-09-02 13:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 17:32 [PATCH v5 00/20] AMD MCA interrupts rework Yazen Ghannam
2025-08-25 17:32 ` [PATCH v5 01/20] x86/mce/amd: Rename threshold restart function Yazen Ghannam
2025-08-25 17:32 ` [PATCH v5 02/20] x86/mce/amd: Remove return value for mce_threshold_{create,remove}_device() Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 03/20] x86/mce/amd: Remove smca_banks_map Yazen Ghannam
2025-08-25 18:19 ` Borislav Petkov
2025-08-25 19:54 ` Yazen Ghannam
2025-09-05 11:40 ` [tip: ras/core] " tip-bot2 for Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 04/20] x86/mce/amd: Put list_head in threshold_bank Yazen Ghannam
2025-09-01 15:41 ` Nikolay Borisov
2025-09-01 16:41 ` Borislav Petkov
2025-08-25 17:33 ` [PATCH v5 05/20] x86/mce: Cleanup bank processing on init Yazen Ghannam
2025-08-26 12:35 ` Borislav Petkov
2025-08-26 13:47 ` Yazen Ghannam
2025-08-26 14:33 ` Borislav Petkov
2025-09-05 11:40 ` [tip: ras/core] " tip-bot2 for Borislav Petkov
2025-08-25 17:33 ` [PATCH v5 06/20] x86/mce: Remove __mcheck_cpu_init_early() Yazen Ghannam
2025-09-05 11:40 ` [tip: ras/core] " tip-bot2 for Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 07/20] x86/mce: Reorder __mcheck_cpu_init_generic() call Yazen Ghannam
2025-09-01 17:07 ` Borislav Petkov
2025-09-02 13:30 ` Yazen Ghannam [this message]
2025-09-02 16:26 ` Borislav Petkov
2025-09-02 17:14 ` Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 08/20] x86/mce: Define BSP-only init Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 09/20] x86/mce: Define BSP-only SMCA init Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 10/20] x86/mce: Do 'UNKNOWN' vendor check early Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 11/20] x86/mce: Separate global and per-CPU quirks Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 12/20] x86/mce: Move machine_check_poll() status checks to helper functions Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 13/20] x86/mce: Unify AMD THR handler with MCA Polling Yazen Ghannam
2025-09-02 11:10 ` Borislav Petkov
2025-09-02 13:37 ` Yazen Ghannam
2025-09-02 17:04 ` Borislav Petkov
2025-09-02 17:25 ` Yazen Ghannam
2025-09-03 9:48 ` Borislav Petkov
2025-08-25 17:33 ` [PATCH v5 14/20] x86/mce: Unify AMD DFR " Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 15/20] x86/mce/amd: Enable interrupt vectors once per-CPU on SMCA systems Yazen Ghannam
2025-09-03 10:03 ` Borislav Petkov
2025-09-03 14:00 ` Yazen Ghannam
2025-09-03 15:39 ` Borislav Petkov
2025-08-25 17:33 ` [PATCH v5 16/20] x86/mce/amd: Support SMCA Corrected Error Interrupt Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 17/20] x86/mce/amd: Remove redundant reset_block() Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 18/20] x86/mce/amd: Define threshold restart function for banks Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 19/20] x86/mce: Handle AMD threshold interrupt storms Yazen Ghannam
2025-08-25 17:33 ` [PATCH v5 20/20] x86/mce: Save and use APEI corrected threshold limit Yazen Ghannam
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=20250902133015.GA18483@yaz-khff2.amd.com \
--to=yazen.ghannam@amd.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=bp@alien8.de \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=qiuxu.zhuo@intel.com \
--cc=rafael@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.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 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®