From: Dave Hansen <dave.hansen@intel.com>
To: Fenghua Yu <fenghua.yu@intel.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Asit K Mallick <asit.k.mallick@intel.com>,
Glenn Williamson <glenn.p.williamson@intel.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context
Date: Wed, 29 Apr 2015 06:53:35 -0700 [thread overview]
Message-ID: <5540E25F.20303@intel.com> (raw)
In-Reply-To: <1429678319-61356-3-git-send-email-fenghua.yu@intel.com>
On 04/21/2015 09:51 PM, Fenghua Yu wrote:
> +static int copy_to_user_xstate(void __user *buf_fx, struct xsave_struct *xsave)
I was thinking about this a bit more. I think uncompacting the xsave
state from the kernel buffer in to the user buffer in software is
probably a bad idea.
It would nice, eventually, to not need to memset() the entire xsave
state when we initialize it. It could be a lot bigger some day, and we
might start to notice the memset() cost. We can't do this unless we're
careful about copying uninitialized parts of the task xstate buffer out
to userspace.
The whole reason we've gone down this path is that we are
!user_has_fpu(), so there is no FPU state in the registers which we can
xsave directly. Perhaps we should enable the FPU hardware, restore the
state to the registers (from the xstate buffer), and then use
xsave_user() to write the user xstate buffer.
This *might* even be faster. But, it *is* a slow (and rare) path, so it
does not really matter what we do performance-wise. What I've described
above should be a lot less code than what we've got now. It makes the
hardware do the hard work.
next prev parent reply other threads:[~2015-04-29 13:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 4:51 [PATCH Bugfix v2 0/4] x86/xsave/xsaves: Fix a few xsave/xsaves related bugs Fenghua Yu
2015-04-22 4:51 ` [PATCH Bugfix v2 1/4] x86/xsave.c: Fix xstate offsets and sizes enumeration Fenghua Yu
2015-04-22 4:51 ` [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Fenghua Yu
2015-04-22 18:45 ` Dave Hansen
2015-04-22 19:05 ` Yu, Fenghua
2015-04-22 19:34 ` Dave Hansen
2015-04-23 0:06 ` Yu, Fenghua
2015-04-23 0:21 ` Dave Hansen
2015-04-23 0:23 ` Yu, Fenghua
2015-04-23 0:34 ` Dave Hansen
2015-04-23 17:09 ` Yu, Fenghua
2015-04-23 21:32 ` Dave Hansen
2015-04-28 14:28 ` Dave Hansen
2015-04-28 22:09 ` Dave Hansen
2015-04-28 22:11 ` Yu, Fenghua
2015-04-29 13:53 ` Dave Hansen [this message]
2015-04-22 4:51 ` [PATCH Bugfix v2 3/4] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Fenghua Yu
2015-04-22 4:51 ` [PATCH Bugfix v2 4/4] x86/xsave: Don't add new states in xsave_struct Fenghua Yu
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=5540E25F.20303@intel.com \
--to=dave.hansen@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=fenghua.yu@intel.com \
--cc=glenn.p.williamson@intel.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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