[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