On Sat, 2018-02-10 at 23:39 +0000, David Woodhouse wrote:
>
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -123,8 +123,6 @@ static const struct sku_microcode
> spectre_bad_microcodes[] = {
> { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x84 },
> { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e },
> { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c },
> - { INTEL_FAM6_SKYLAKE_MOBILE, 0x03, 0xc2 },
> - { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 },
> { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 },
> { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b },
> { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 },
Arjan points out that the SKYLAKE_DESKTOP one there is premature. There
are *two* rows in Intel's table which match that CPUID (506E3).
Only *one* of them ("Skylake H/S") has cleared the 0xC2 microcode for
use, while the "Skylake E3" line still doesn't approve it. (But doesn't
explicitly list it in the "STOP deploying" column any more either,
which it probably should, and might have helped me notice.)
Ingo, Thomas: do you want to drop this patch which is already in
tip/x86/pti and have a new version with the SKYLAKE_DESKTOP no longer
removed? Or shall I send an incremental patch to add it back?Attachment:
smime.p7s
Description: S/MIME cryptographic signature
