Re: [PATCH v2 1/2] x86/mce/amd: Fix inverted interrupt enablement during storm handling

I'm ok with the queued patch because it still fixes an important bug
(disabling interrupts on storm end is not correct). The rest of this
reply is talking about the concern that storms are not handled
properly in the AMD driver. I can make that a new patch thread if we
agree to make the behavior more Intel like.

On Tue, Aug 18, 2026 at 12:03 PM Borislav Petkov <[email protected]> wrote:
> On Mon, Aug 17, 2026 at 12:51:08PM -0600, Jasjeet Rangi wrote:
> > Inverting `on` in mce_amd_handle_storm() alone is not enough because
> > clear_bank() will immediately and unconditionally enable the interrupt
> > again.
>
> And?
>
> What would happen then?
>
> Did you read my previous reply?

On AMD a machine_check_poll() call will not necessarily set ErrCnt to 0.
In fact, it will not reset ErrCnt at all unless the overflow bit is
set. And the overflow bit gets set when it's time to generate an
interrupt. (Yazen and Smita please correct me if I'm wrong)

The threshold is not always high on AMD either. Since eeb3f76d73ba
(x86/mce: Save and use APEI corrected threshold limit)
it gets the value from the BIOS. The default on an AMD system I was
using was only 10. So ErrCnt will get reset to 4085 on that system
when the overflow bit is set. That is enough to not meaningfully
reduce the interrupt rate during an interrupt storm.

Unlike Intel, the AMD driver doesn't set the threshold to an extremely
large value when storm mode is turned on. It keeps it set to the same
configured value (default from BIOS).

So if interrupts are left enabled during storm mode like they would be
even with the queued patch, the AMD driver doesn't really reduce the
interrupt rate during a storm like the Intel driver does.

If we don't want to diverge from Intel, then the correct thing to do is
to update the AMD driver to do what the Intel driver does. I.e. don't
disable interrupts, but set the threshold_limit to a large value like
THRESHOLD_MAX during storm on, and restore it to what it was before upon
storm off.

> Yeah, we don't protect users from themselves, you know :)

I don't think having threshold=1 on AMD is too crazy. On the Intel
driver for example it defaults to 1 if not overridden by the BIOS.
```
/* Linux non-storm CMCI threshold (may be overridden by BIOS) */
#define CMCI_THRESHOLD		1
```

> We do clear MCi_MISC[ErrCnt] to 0 so that's the "highest' value we can do
> before we raise an interrupt there :)
And on AMD it does not get set to 0 after an interrupt. It gets set to
THRESHOLD_MAX - threshold_limit. So if your limit is 10, the ErrCnt will
get reset to 4085. This is the behavior since eeb3f76d73ba
(x86/mce: Save and use APEI corrected threshold limit). Prior to that
ErrCnt would get reset to 0 by default on AMD.

Thanks,
Jasjeet