Re: [PATCH v2] x86/idle: prevent entering C6 with in service interrupts on Intel

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, May 11, 2020 at 01:07:43PM +0200, Roger Pau Monné wrote:
> On Mon, May 11, 2020 at 11:38:49AM +0100, Andrew Cooper wrote:
> > On 11/05/2020 11:17, Roger Pau Monne wrote:
> > > Apply a workaround for Intel errata CLX30: "A Pending Fixed Interrupt
> > > May Be Dispatched Before an Interrupt of The Same Priority Completes".
> > >
> > > It's not clear which models are affected, as the errata is listed in
> > > the "Second Generation Intel Xeon Scalable Processors" specification
> > > update, but the issue has been seen as far back as Nehalem processors.
> > 
> > Really?  I'm only aware of it being Haswell and later.

So I've found the following related erratas:

BDX99: E7-8800 v4, E7-4800 v4 (Broadwell)
CLX30: 2nd Gen Xeon Scalable (Cascade Lake)
SKX100: Xeon Scalable (Skylake)
CFW125: E-2100, E-2200 (Kaby Lake)
BDF104: E5-2600 v4 (Broadwell)
BDH85: i7 LGA2011 v3 socket (Broadwell)
BDM135: 5th Gen Intel Core, Core-M, Mobile Intel Pentium/Celeron (Broadwell)
KBW131: E3-1200 v6 (Kaby Lake)

So my plan would be to cover all chips from Broadwell to Cascade Lake,
this would be: Broadwell, Skylake, Kaby Lake, Coffee Lake,
{Cannon/Whiskey/Amber} Lake and Cascade Lake. I haven't found any
mention of the issue in the Haswell specification updates, and the one
for Xeon E7 v3 was last updated in April 2020.

I think the list of IDs to match against should be:

#define INTEL_FAM6_MODEL(m) { X86_VENDOR_INTEL, 6, m, X86_FEATURE_ALWAYS }
{
    /* Broadwell */
    INTEL_FAM6_MODEL(0x47),
    INTEL_FAM6_MODEL(0x3d),
    INTEL_FAM6_MODEL(0x4f),
    INTEL_FAM6_MODEL(0x56),
    /* Skylake (client) */
    INTEL_FAM6_MODEL(0x5e),
    INTEL_FAM6_MODEL(0x4e),
    /* {Sky/Cascade}lake (server) */
    INTEL_FAM6_MODEL(0x55),
    /* {Kaby/Coffee/Whiskey/Amber} Lake */
    INTEL_FAM6_MODEL(0x9e),
    INTEL_FAM6_MODEL(0x8e),
    /* Cannon Lake */
    INTEL_FAM6_MODEL(0x66),
    {}
}

Let me know if that sounds sensible.

Thanks, Roger.