From: Dave Hansen <dave.hansen@linux.intel.com>
To: Keno Fischer <keno@juliacomputing.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Borislav Petkov" <bp@suse.de>,
"Andi Kleen" <andi@firstfloor.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Kyle Huey" <khuey@kylehuey.com>,
"Robert O'Callahan" <robert@ocallahan.org>
Subject: Re: [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread
Date: Mon, 18 Jun 2018 08:04:09 -0700 [thread overview]
Message-ID: <11347d3a-8491-1545-d47d-a1cb2fb9b410@linux.intel.com> (raw)
In-Reply-To: <CABV8kRwhrQ75g9y7v4Mq05CfZ9khhVQCwkp052jcNOvKs6-2Fg@mail.gmail.com>
On 06/18/2018 07:42 AM, Keno Fischer wrote:
>> There's no way this is even close to viable until it has been made to
>> cope with holes.
>
> Ok, it seems to me the first decision is whether it should be allowed
> to have the compacted format (with holes) in an in-memory xstate
> image. Doing so seems possible, but would require more invasive
> changes to the kernel, so I'm gonna ignore it for now.
>
> If we want to keep the in-memory xstate layout constant after boot
> time, I see four ways to do that for this feature.
>
> 1) Set up XCR0 in a different place, so that the kernel xsaves/xrstors
> use an XCR0 that matches the layout the kernel expects.
... and do XCR0 writes before every XSAVES/XRSTORS, including in the
context-switch path?
> 2) Use xsaveopt when this particular thread flag is set and have the
> kernel be able to deal with non-compressed xstate images, even
> if xsaves is available.
What about if there is supervisor state in place?
> 3) What's in this patch now, but fix up the xstate after saving it.
That's _maybe_ viable. But, it's going to slow things down quite a bit
and has to be done with preempt disabled.
> 4) Catch the fault thrown by xsaves/xrestors in this situation, update
> XCR0, redo the xsaves/restores, put XCR0 back and continue
> execution after the faulting instruction.
I'm worried about the kernel pieces that go digging in the XSAVE data
getting confused more than the hardware getting confused.
> Option 1) seems easiest, but it would also require adding code
> somewhere on the common path, which I assume is a no-go ;).
Yeah, that would be horribly slow.
You then also have to be really careful with interrupts and preempt when
you're in a funky XCR0 configuration.
> Option 3) seems doable entirely in the slow path for this feature.
> If we xsaves with the modified XCR0, we can then fix up the memory
> image to match the expected layout. Similarly, we could xrestors
> in the slow path (from standard layout) and rely on the
> `fpregs_state_valid` mechanism to prevent the fault.
... with one more modification. You need two buffers _anyway_ if you do
this. So you would probably just XSAVE to a new buffer and then convert
that back to the "real" buffer in the thread struct.
> At least currently, it is my understanding that `xfeatures_mask` only has
> user features, am I mistaken about that?
We're slowing adding supervisor support. I think accounting for
supervisor features is a requirement for any new XSAVE code.
next prev parent reply other threads:[~2018-06-18 15:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-17 0:33 [RFC PATCH] x86/arch_prctl: Add ARCH_SET_XCR0 to mask XCR0 per-thread Keno Fischer
2018-06-17 16:35 ` Andi Kleen
2018-06-17 16:48 ` Keno Fischer
2018-06-17 18:22 ` Keno Fischer
2018-06-18 16:58 ` Andi Kleen
2018-06-18 17:50 ` Keno Fischer
2018-06-19 13:43 ` Andi Kleen
2018-06-18 12:47 ` Dave Hansen
2018-06-18 14:42 ` Keno Fischer
2018-06-18 15:04 ` Dave Hansen [this message]
2018-06-18 15:13 ` Keno Fischer
2018-06-18 16:16 ` Dave Hansen
2018-06-18 17:22 ` Keno Fischer
2018-06-18 17:29 ` Dave Hansen
2018-06-18 17:43 ` Dave Hansen
2018-06-18 18:16 ` Keno Fischer
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=11347d3a-8491-1545-d47d-a1cb2fb9b410@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=keno@juliacomputing.com \
--cc=khuey@kylehuey.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=robert@ocallahan.org \
--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;
as well as URLs for NNTP newsgroup(s).