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 15/20] x86/mce/amd: Enable interrupt vectors once per-CPU on SMCA systems
Date: Wed, 3 Sep 2025 10:00:22 -0400 [thread overview]
Message-ID: <20250903140022.GA835@yaz-khff2.amd.com> (raw)
In-Reply-To: <20250903100317.GHaLgSZTPMDHrKbO7Q@fat_crate.local>
On Wed, Sep 03, 2025 at 12:03:17PM +0200, Borislav Petkov wrote:
> On Mon, Aug 25, 2025 at 05:33:12PM +0000, Yazen Ghannam wrote:
> > Scalable MCA systems have a per-CPU register that gives the APIC LVT
> > offset for the thresholding and deferred error interrupts.
> >
> > Currently, this register is read once to set up the deferred error
> > interrupt and then read again for each thresholding block. Furthermore,
> > the APIC LVT registers are configured each time, but they only need to
> > be configured once per-CPU.
> >
> > Move the APIC LVT setup to the early part of CPU init, so that the
> > registers are set up once. Also, this ensures that the kernel is ready
> > to service the interrupts before the individual error sources (each MCA
> > bank) are enabled.
> >
> > Apply this change only to SMCA systems to avoid breaking any legacy
> > behavior. The deferred error interrupt is technically advertised by the
> > SUCCOR feature. However, this was first made available on SMCA systems.
> > Therefore, only set up the deferred error interrupt on SMCA systems and
> > simplify the code.
> >
> > Guidance from hardware designers is that the LVT offsets provided from
> > the platform should be used. The kernel should not try to enforce
> > specific values. However, the kernel should check that an LVT offset is
> > not reused for multiple sources.
> >
> > Therefore, remove the extra checking and value enforcement from the MCE
> > code. The "reuse/conflict" case is already handled in
> > setup_APIC_eilvt().
> >
> > Tested-by: Tony Luck <tony.luck@intel.com>
> > Reviewed-by: Tony Luck <tony.luck@intel.com>
> > Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
>
> Some touchups ontop:
>
> diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
> index c05d9c6f07d1..5722806ccaa5 100644
> --- a/arch/x86/kernel/cpu/mce/amd.c
> +++ b/arch/x86/kernel/cpu/mce/amd.c
> @@ -54,8 +54,10 @@ static bool thresholding_irq_en;
> struct mce_amd_cpu_data {
> mce_banks_t thr_intr_banks;
> mce_banks_t dfr_intr_banks;
> - bool thr_intr_en;
> - bool dfr_intr_en;
> +
> + u32 thr_intr_en: 1,
> + dfr_intr_en: 1,
> + __resv: 30;
> };
Thanks, I'll include these.
But any reason to use u32? Why not u8? Alignment or something?
The u32 is double the two bools that it replaces.
Thanks,
Yazen
next prev parent reply other threads:[~2025-09-03 14:00 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
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 [this message]
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=20250903140022.GA835@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®