From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
To: Dave Hansen <dave.hansen@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
hpa@zytor.com, jon.grimm@amd.com,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Thomas Lendacky <Thomas.Lendacky@amd.com>
Subject: Re: [PATCH] x86/fpu: Warn only when CPU-provided sizes less than struct declaration
Date: Mon, 13 Jan 2020 16:54:52 +0700 [thread overview]
Message-ID: <71a863a0-800b-0f3b-0846-839512f38208@amd.com> (raw)
In-Reply-To: <bac4b1ee-de8c-5e50-dc11-ab432ca0f6af@amd.com>
Dave,
On 12/12/19 1:52 PM, Suravee Suthikulpanit wrote:
>
> On 12/11/2019 9:13 PM, Dave Hansen wrote:
>> On 12/10/19 9:24 PM, Suravee Suthikulpanit wrote:
>>> The value returned by ECX[1] indicates the alignment of state
>>> component i when the compacted format of the extended region of an
>>> XSAVE area is used (see Section 13.4.3). If ECX[1] returns 0, state
>>> component i is located immediately following the preceding state
>>> component; if ECX[1] returns 1, state component i is located on the
>>> next 64-byte boundary following the preceding state component.
>>
>> Essentially, if an implementation needs state alignment or (up to) 64
>> bytes of padding, it could use this existing architecture for it.
>
> Let me check with the HW folks and get back to you on this.
I don't think the 64-byte aligned bit alone would help with the PKRU size mismatch warning in
check_xstate_against_struct() that we are seeing.
Here is the description from the section 13.4.3, for the compacted format:
* Let j, 2 ≤ j < i, be the greatest value such that XCOMP_BV[j] = 1. Then locationI is
determined by the following values: locationJ; sizeJ, as enumerated in CPUID.(EAX=0DH,ECX=j):EAX;
and the value of alignI, as enumerated in CPUID.(EAX=0DH,ECX=i):ECX[1]:
— If alignI = 0, locationI = locationJ + sizeJ. (This item implies that state component i is located immediately
following the preceding state component whose bit is set in XCOMP_BV.)
— If alignI = 1, locationI = ceiling(locationJ + sizeJ, 64). (This item implies that state component i is located on
the next 64-byte boundary following the preceding state component whose bit is set in XCOMP_BV.)
According to the description above, since we need to add padding for PKRU state, if we set the aligned bit of the
subsequent feature after PKRU state, the current Linux kernel would still generate the warning for PKRU since the
check_xstate_against_struct() does not currently take into account of the align bit (which is only for compact mode).
It would also generate another warning in do_extra_xstate_size_checks() due to XSTATE_WARN_ON(paranoid_xstate_size !=
fpu_kernel_xstate_size) (see https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/fpu/xstate.c#L608). Note
that the paranoid_xstate_size takes into account of the 64-byte alignment in the size calculation, but the
fpu_kernel_xstate_size takes the size reported by CPUID function 0DH, sub-function 0 or 1. So, this logic might need to
change as well.
As for the PKRU size, it should really be 4 bytes (regardless of the alignment) since that's the size of actual PKRU
register, but it seems that the 4-byte padding in struct pkru_state was added to match the Intel's CPUID-report size of
8. Now we also have AMD hardware reporting PKRU size of 32 (also mainly for padding). We shouldn't keep the same warning
logic in check_xstate_against_struct().
Please let me know if I am still missing anything.
Thanks,
Suravee
next prev parent reply other threads:[~2020-01-13 9:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-03 9:01 Suravee Suthikulpanit
2019-12-03 10:34 ` Sebastian Andrzej Siewior
2019-12-06 8:14 ` Suravee Suthikulpanit
2019-12-03 17:27 ` Dave Hansen
2019-12-06 8:14 ` Suravee Suthikulpanit
2019-12-06 15:28 ` Dave Hansen
2019-12-11 5:24 ` Suravee Suthikulpanit
2019-12-11 14:13 ` Dave Hansen
2019-12-12 6:52 ` Suravee Suthikulpanit
2020-01-13 9:54 ` Suravee Suthikulpanit [this message]
2020-01-15 16:54 ` Dave Hansen
2020-04-29 19:18 ` AMD / Memory Protection Keys Dave Hansen
2020-05-01 23:50 ` Suravee Suthikulpanit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71a863a0-800b-0f3b-0846-839512f38208@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=jon.grimm@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®