On 26/09/2019 00:12, speck for Dave Hansen wrote:
> 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.

MISC_ENABLES.{LIMIT_CPUID,XD_DISABLE}

Any kernel with knowledge of this new TSX MSR should set it to a sane
state as part of coming up, whether it is transitioning out of the
firmware, or from a previous kernel.

~Andrew