Re: [RFC 05/10] x86/speculation: Add basic IBRS support infrastructure

From: Peter Zijlstra
Date: Wed Jan 24 2018 - 07:29:27 EST


On Wed, Jan 24, 2018 at 12:14:51PM +0000, David Woodhouse wrote:
> On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> >
> > Typically tglx likes to use x86_match_cpu() for these things; see also
> > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> > errata").
>
> Ewww.
>
> static u32 hsx_deadline_rev(void)
> {
>        switch (boot_cpu_data.x86_mask) {
>        case 0x02: return 0x3a; /* EP */
>        case 0x04: return 0x0f; /* EX */
>        }
>
>        return ~0U;
> }
> ...
> static const struct x86_cpu_id deadline_match[] = {
>        DEADLINE_MODEL_MATCH_FUNC( INTEL_FAM6_HASWELL_X,        hsx_deadline_rev),
>        DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_BROADWELL_X,      0x0b000020),
>        DEADLINE_MODEL_MATCH_FUNC( INTEL_FAM6_BROADWELL_XEON_D, bdx_deadline_rev),
>        DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_SKYLAKE_X,        0x02000014),
> ...
>
>        /*
>         * Function pointers will have the MSB set due to address layout,
>         * immediate revisions will not.
>         */
>        if ((long)m->driver_data < 0)
>                rev = ((u32 (*)(void))(m->driver_data))();
>        else
>                rev = (u32)m->driver_data;
>
> EWWWW!
>

Yes :/

We could look at extending x86_cpu_id and x86_match_cpu with a stepping
option I suppose, but that might be lots of churn.

Thomas?