[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.
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.