[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zhb9ycwu.fsf@nanos.tec.linutronix.de>
Date: Sat, 18 Apr 2020 00:18:09 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Luck\, Tony" <tony.luck@...el.com>
Cc: Ingo Molnar <mingo@...nel.org>, Fenghua Yu <fenghua.yu@...el.com>,
Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
Ashok Raj <ashok.raj@...el.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Andy Lutomirski <luto@...nel.org>,
linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 2/3] x86/split_lock: Bits in IA32_CORE_CAPABILITIES are not architectural
"Luck, Tony" <tony.luck@...el.com> writes:
> On Fri, Apr 17, 2020 at 11:07:37PM +0200, Thomas Gleixner wrote:
>> Thomas Gleixner <tglx@...utronix.de> writes:
>> as I fear that the infinite wisdom of HW folks will add yet another
>> variant in the foreseeable future, I used a switch() right away and
>> tweaked the comments a bit.
>>
>> Can you have a look, please?
>
> Looks like you are all ready for "case 2:" when Intel produces
> a less sucky implementation of split lock detect. Don't hold your
> breath waiting for that :-)
Surely not.
I'm still hoping to see quirkless TSCs and timers, sane IRET semantics
and the demise of non-maskable MSIs before my retirement. Not that I
believe it will happen, it's just because hope dies last.
> Looks good. Should be a useful template for any future
> bits that show up in CORE_CAPABILITIES.
Groan. No!
Thanks,
tglx
Powered by blists - more mailing lists