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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.05.2020 13:17, Andrew Cooper wrote:
> 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.

I'm afraid I don't fully follow: For one, does what you say imply HLE is
no longer enumerated in CPUID? If so, and if we assume all CPU models
listed have had suitable ucode updates issued, we could indeed drop the
workaround (as taking effect only when HLE is enumerated). But then this
erratum does not have the usual text effectively meaning that an ucode
update is or will be available to address the issue; instead it says
that BIOS or VMM can reserve the respective address range. This -
assuming the alternative you describe is indeed viable - then is surely
a much more intrusive workaround than needed. Which I wouldn't assume
they would suggest in such a case.

Jan