[MODERATED] Re: [PATCH v4 03/10] TAAv4 3
Dave Hansen <[email protected]>
| Newsgroups | org.kernel.lore.historical-speck |
|---|---|
| Message-ID | <[email protected]> |
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.