From: Suresh Siddha <suresh.b.siddha@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Mikael Pettersson <mikpe@it.uu.se>,
Andi Kleen <andi@firstfloor.org>,
mingo@elte.hu, tglx@linutronix.de, torvalds@linux-foundation.org,
akpm@linux-foundation.org, roland@redhat.com, drepper@redhat.com,
Hongjiu.lu@intel.com, linux-kernel@vger.kernel.org,
arjan@linux.intel.com, rmk+lkml@arm.linux.org.uk, dan@debian.org,
asit.k.mallick@intel.com
Subject: Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Date: Thu, 22 May 2008 14:29:21 -0700 [thread overview]
Message-ID: <20080522212920.GC7998@linux-os.sc.intel.com> (raw)
In-Reply-To: <4835DF64.6080104@zytor.com>
On Thu, May 22, 2008 at 02:02:28PM -0700, H. Peter Anvin wrote:
> Suresh Siddha wrote:
> >
> >hpa, What is the virtualization problem? Are you referring to perf problem?
> >As you noted, regular non-rt signal handlers won't need this cpuid check.
> >It's
> >needed only for those who manually look at non-rt signal frames and
> >interpret it.
> >And also, they can do this check only once and not everytime.
> >
>
> No, relying on CPUID and vdso both have implications for virtualization.
can you please elaborate? even in presence of virtualization, appropriate
cpuid bits need to be set/visible for application, for xsave/xrstor to work
properly.
> I don't think it is ... it's not overkill but rather "underkill"... it's
> a low-performance solution but it's guaranteed to be safe in the
> presence of virtualization of all its various ilk. Note that you don't
> need to be able to *set* the format via prctl(), just *query* (get) it.
>
> Using prctl() allows us to make this personality-dependent if we ever
> need to.
>
> >While restoring from the user, kernel also need to find out what layout
> >the user is passing. So it's bi-directional. I prefer the same mechanism
> >(using cookies/magic numbers etc inaddition to uc_flags or cpuid checks) to
> >interpret the fpstate for both user/kernel.
>
> No, it really doesn't: the kernel only needs to be able to read the same
> format as it itself wrote.
But user can potentially change the _fpstate pointer in sigcontext struct.
>
> >ARM also seem to be using similar things while extending their ucontext_t,
> >with out other kernel interfaces to indicate the layout.
> >
> >BTW, how come 32bit kernel doesn't have the X86_FXSR_MAGIC checks, while
> >restoring
> >the extended fxsave data from _fpstate?
>
> Again, the kernel already knows the format, so it doesn't need to check.
What happens with some old applications which change the _fpstate
pointer. they may or may not be fxsave aware...
thanks,
suresh
next prev parent reply other threads:[~2008-05-22 21:29 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-13 1:10 [RFC] x86: xsave/xrstor support, ucontext_t extensions Suresh Siddha
2008-05-16 13:26 ` Mikael Pettersson
2008-05-18 1:34 ` Suresh Siddha
2008-05-19 14:52 ` Mikael Pettersson
2008-05-19 15:04 ` Andi Kleen
2008-05-19 16:29 ` H. Peter Anvin
2008-05-19 16:57 ` Suresh Siddha
2008-05-19 17:45 ` H. Peter Anvin
2008-05-20 1:57 ` Suresh Siddha
2008-05-20 8:58 ` Mikael Pettersson
2008-05-20 10:01 ` Andi Kleen
2008-05-20 13:19 ` Mikael Pettersson
2008-05-20 14:58 ` H. Peter Anvin
2008-05-20 15:20 ` Mikael Pettersson
2008-05-20 17:53 ` Suresh Siddha
2008-05-20 17:59 ` H. Peter Anvin
2008-05-22 0:28 ` H. Peter Anvin
2008-05-22 0:53 ` Roland McGrath
2008-05-22 1:38 ` H. Peter Anvin
2008-05-22 6:40 ` Roland McGrath
2008-05-22 7:18 ` H. Peter Anvin
2008-05-22 8:49 ` Mikael Pettersson
2008-05-22 8:57 ` Mikael Pettersson
2008-05-22 20:56 ` Suresh Siddha
2008-05-22 21:02 ` H. Peter Anvin
2008-05-22 21:29 ` Suresh Siddha [this message]
2008-05-22 21:34 ` H. Peter Anvin
2008-05-22 22:22 ` Mikael Pettersson
2008-05-23 1:48 ` Suresh Siddha
2008-05-23 2:12 ` Roland McGrath
2008-05-23 2:49 ` H. Peter Anvin
2008-05-23 18:09 ` Suresh Siddha
2008-06-06 0:28 ` x86: xsave/xrstor support; " H. Peter Anvin
2008-06-06 20:14 ` Suresh Siddha
2008-06-06 23:03 ` H. Peter Anvin
2008-05-23 2:45 ` [RFC] x86: xsave/xrstor support, " H. Peter Anvin
2008-05-23 11:46 ` Mikael Pettersson
2008-05-23 12:11 ` Andi Kleen
2008-05-22 21:32 ` Chris Wright
2008-05-22 22:15 ` Mikael Pettersson
2008-05-22 22:29 ` Chris Wright
2008-05-23 0:32 ` H. Peter Anvin
2008-05-23 0:44 ` Chris Wright
2008-05-22 22:36 ` Mikael Pettersson
2008-05-23 0:33 ` H. Peter Anvin
2008-05-23 0:42 ` Suresh Siddha
2008-05-23 1:33 ` Roland McGrath
2008-05-23 16:57 ` H. Peter Anvin
2008-05-23 17:50 ` Suresh Siddha
2008-05-23 2:27 ` H. Peter Anvin
2008-05-20 17:57 ` H. Peter Anvin
2008-05-20 14:55 ` H. Peter Anvin
2008-05-20 15:03 ` Andi Kleen
2008-05-20 20:10 ` Roland McGrath
2008-05-22 0:05 ` H. Peter Anvin
2008-05-22 0:47 ` Roland McGrath
2008-05-22 8:14 ` Andi Kleen
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=20080522212920.GC7998@linux-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--cc=Hongjiu.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=asit.k.mallick@intel.com \
--cc=dan@debian.org \
--cc=drepper@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=mingo@elte.hu \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.