Re: [PATCH] x86: extend coverage of HLE "bad page" workaround

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/05/2020 07:49, Jan Beulich wrote:
> Respective Core Gen10 processor lines are affected, too.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6045,6 +6045,8 @@ const struct platform_bad_page *__init g
>      case 0x000506e0: /* errata SKL167 / SKW159 */
>      case 0x000806e0: /* erratum KBL??? */
>      case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
> +    case 0x000a0650: /* erratum Core Gen10 U/H/S 101 */
> +    case 0x000a0660: /* erratum Core Gen10 U/H/S 101 */

This is marred in complexity.

The enumeration of MSR_TSX_CTRL (from the TAA fix, but architectural
moving forwards on any TSX-enabled CPU) includes a confirmation that HLE
no longer exists/works.  This applies to IceLake systems, but possibly
not their initial release configuration (hence, via a later microcode
update).

HLE is also disabled in microcode on all older parts for errata reasons,
so in practice it doesn't exist anywhere now.

I think it is safe to drop this workaround, and this does seem a more
simple option than encoding which microcode turned HLE off (which sadly
isn't covered by the spec updates, as even when turned off, HLE is still
functioning according to its spec of "may speed things up, may do
nothing"), or the interactions with the CPUID hiding capabilities of
MSR_TSX_CTRL.

~Andrew

>          *array_size = (cpuid_eax(0) >= 7 && !cpu_has_hypervisor &&
>                         (cpuid_count_ebx(7, 0) & 
> cpufeat_mask(X86_FEATURE_HLE)));
>          return &hle_bad_page;