From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Rik van Riel <riel@surriel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Fenghua Yu <fenghua.yu@intel.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 8/8] x86/fpu/xstate: Restore supervisor xstates for __fpu__restore_sig()
Date: Fri, 28 Feb 2020 10:11:44 -0800 [thread overview]
Message-ID: <9a283ad42da140d73de680b1975da142e62e016e.camel@intel.com> (raw)
In-Reply-To: <20200228172202.GD25261@zn.tnic>
On Fri, 2020-02-28 at 18:22 +0100, Borislav Petkov wrote:
> On Fri, Feb 28, 2020 at 08:20:27AM -0800, Yu-cheng Yu wrote:
> > When XSAVES writes to an xsave buffer, xsave->header.xcomp_bv is set to
> > include only saved components, effectively changing the buffer's format.
>
> So you want to *save* the supervisor states and xcomp_bv will be set to
> supervisor states only and since we don't care about the user states
> there - they will be loaded later - we're good.
No!
> Or do you have to set xcomp_bv later in order to save the user
> components too and also rearrange the buffer to undo the format change
> above?
That is the case. If we save only supervisor states, the buffer becomes
smaller and has only supervisor states.
> We have using_compacted_format() and we do conversion from compacted to
> standard buffers - I'm looking at copy_xstate_to_kernel() et al - so it
> shouldn't be impossible. So to repeat Sebastian's question which you
> ignored:
>
> "How large is this supervisor state at most? I guess saving the AVX512
> state just to get the 2 bytes of the supervisor state at the right spot
> is not really optimal."
I thought Sebastian was saying XSAVES is not optimal.
CET has 16 bytes for ring-3 setting, 24 bytes for ring-0.
Saving supervisor states somewhere else and copying back is not better
either.
> In any case, this performance penalty better be paid only by those
> who are actually using some supervisor states. I haven't looked at
> the CET patchset but I'm assuming you're setting the CET bit in
> xfeatures_mask_all only when the feature is being actually used?
We save supervisor states only when xfeatures_mask_supervisor() is not
zero.
Yu-cheng
next prev parent reply other threads:[~2020-02-28 18:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 20:18 [PATCH v2 0/8] Support XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates Yu-cheng Yu
2020-02-20 11:47 ` Borislav Petkov
2020-02-20 20:23 ` Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 2/8] x86/fpu/xstate: Separate user and supervisor xfeatures mask Yu-cheng Yu
2020-02-21 10:34 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 3/8] x86/fpu/xstate: Introduce XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 4/8] x86/fpu/xstate: Define new functions for clearing fpregs and xstates Yu-cheng Yu
2020-02-21 14:04 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 5/8] x86/fpu/xstate: Rename validate_xstate_header() to validate_xstate_header_from_user() Yu-cheng Yu
2020-02-21 14:13 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 6/8] x86/fpu/xstate: Update sanitize_restored_xstate() for supervisor xstates Yu-cheng Yu
2020-02-21 14:30 ` Borislav Petkov
2020-01-21 20:18 ` [PATCH v2 7/8] x86/fpu/xstate: Update copy_kernel_to_xregs_err() for XSAVES supervisor states Yu-cheng Yu
2020-01-21 20:18 ` [PATCH v2 8/8] x86/fpu/xstate: Restore supervisor xstates for __fpu__restore_sig() Yu-cheng Yu
2020-02-21 17:58 ` Borislav Petkov
2020-02-27 22:52 ` Yu-cheng Yu
2020-02-28 12:17 ` Borislav Petkov
2020-02-28 12:51 ` Sebastian Andrzej Siewior
2020-02-28 15:53 ` Yu-cheng Yu
2020-02-28 16:23 ` Borislav Petkov
2020-02-28 16:20 ` Yu-cheng Yu
2020-02-28 16:50 ` Sebastian Andrzej Siewior
2020-02-28 16:54 ` Yu-cheng Yu
2020-02-28 17:22 ` Borislav Petkov
2020-02-28 18:11 ` Yu-cheng Yu [this message]
2020-02-28 18:31 ` Borislav Petkov
2020-02-28 21:22 ` Yu-cheng Yu
2020-02-28 21:47 ` Borislav Petkov
2020-02-28 22:13 ` Yu-cheng Yu
2020-02-29 14:36 ` Borislav Petkov
2020-03-02 18:09 ` Yu-cheng Yu
2020-03-04 18:18 ` Yu-cheng Yu
2020-03-06 20:50 ` Borislav Petkov
2020-03-10 20:36 ` Yu-cheng Yu
2020-03-10 21:16 ` Thomas Gleixner
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=9a283ad42da140d73de680b1975da142e62e016e.camel@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.