On 9/25/19 3:48 PM, speck for Josh Poimboeuf wrote:
>>>> +static void tsx_enable(void)
>>>> +{
>>>> +	u64 tsx;
>>>> +
>>>> +	rdmsrl(MSR_IA32_TSX_CTRL, tsx);
>>>> +
>>>> +	tsx &= ~MSR_TSX_CTRL_RTM_DISABLE;
>>>> +	tsx &= ~MSR_TSX_CTRL_CPUID_CLEAR;
>>>> +
>>>> +	wrmsrl(MSR_IA32_TSX_CTRL, tsx);
>>>> +}
>>> OK, so in the last patch we went through all the steps to enumerate this
>>> sucker.  Is that still being respected here?
>> This doesn't affect the enumeration, only adds support for tsx=on case.
>>
>>> Also, how would these bits have gotten set so that we need to clear them
>>> here?  kexec?
>> Yes.
> So you're saying we need to support the case where we booted with
> tsx=off, but then want to kexec with tsx=on?
> 
> I don't know, that sounds a little esoteric to me.  Do we actually
> support that type of scenario for other cmdline options?

I can't think of another case where an earlier kernel's actions change a
later kernel's ability to enumerate CPU features.  We always start from
scratch in our enumeration.

I look at it this way: the new MSR_IA32_TSX_CTRL effectively brings new
enabling to enable TSX.  This patch effectively brings TSX in line with
other features, starting the enabling from scratch every time.

It's certainly a weird situation, though.