[MODERATED] Re: [PATCH v4 03/10] TAAv4 3

Andrew Cooper <[email protected]>
Newsgroups org.kernel.lore.historical-speck
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.