[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18af2b84-b350-6bde-9aef-c0266d604e4a@oracle.com>
Date: Tue, 25 May 2021 17:22:55 -0500
From: Dave Kleikamp <dave.kleikamp@...cle.com>
To: Dave Hansen <dave.hansen@...el.com>,
Babu Moger <babu.moger@....com>, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
hpa@...or.com, dave.hansen@...ux.intel.com, luto@...nel.org,
peterz@...radead.org, shuah@...nel.org, jroedel@...e.de,
ubizjak@...il.com, viro@...iv.linux.org.uk, jpa@....mail.kapsi.fi,
fenghua.yu@...el.com, kan.liang@...ux.intel.com,
akpm@...ux-foundation.org, rppt@...nel.org, Fan_Yang@...u.edu.cn,
anshuman.khandual@....com, b.thiel@...teo.de, jgross@...e.com,
keescook@...omium.org, seanjc@...gle.com, mh@...ndium.org,
sashal@...nel.org, krisman@...labora.com, chang.seok.bae@...el.com,
0x7f454c46@...il.com, jhubbard@...dia.com, sandipan@...ux.ibm.com,
ziy@...dia.com, kirill.shutemov@...ux.intel.com,
suxingxing@...ngson.cn, harish@...ux.ibm.com,
rong.a.chen@...el.com, linuxram@...ibm.com, bauerman@...ux.ibm.com
Subject: Re: x86/fpu/xsave: protection key test failures
On 5/25/21 5:18 PM, Dave Hansen wrote:
> On 5/25/21 2:37 PM, Babu Moger wrote:
>> My suspicion at this point is towards the selftest tool protection_keys.c.
>> I will keep looking. Any feedback would be much appreciated to debug further.
>
> The pkey selftest code that pokes at the signal stack is rather hackish.
> If I had to guess, I'd suspect that PKRU ends up in there in a slightly
> different place than on Intel CPUs.
>
> One oddity is that xfeatures seems to lose its pkey bit somewhere:
>
>> protection_keys-17350 [035] 59275.834197: x86_fpu_copy_src: x86/fpu: 0xffff93d7595e2dc0 load: 0 xfeatures: 202 xcomp_bv: 8000000000000207
>> protection_keys-17350 [035] 59275.834197: x86_fpu_copy_dst: x86/fpu: 0xffff93d722877800 load: 0 xfeatures: 2 xcomp_bv: 8000000000000207
>
> The only legitimate way that can happen (on Intel at least) is an XRSTOR
> that brings PKRU back to the init state. That would destroy all
> meaningful PKRU state, unless PKRU=0, which it almost never does on Linux.
>
> What values do PKRU and the shadow have when the test fails? Is PKRU 0?
> Any idea how xfeatures&0x200 got clear?
I did observe that PKRU is 0 right before the failure.
Shouldn't this still be a valid value?
Powered by blists - more mailing lists