[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4832E705.2010900@zytor.com>
Date: Tue, 20 May 2008 07:58:13 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Mikael Pettersson <mikpe@...uu.se>
CC: Andi Kleen <andi@...stfloor.org>,
Suresh Siddha <suresh.b.siddha@...el.com>, mingo@...e.hu,
tglx@...utronix.de, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, roland@...hat.com, drepper@...hat.com,
Hongjiu.lu@...el.com, linux-kernel@...r.kernel.org,
arjan@...ux.intel.com, rmk+lkml@....linux.org.uk, dan@...ian.org,
asit.k.mallick@...el.com
Subject: Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
Mikael Pettersson wrote:
> >
> > Are they always zeroed in earlier CPUs though? If not that wouldn't
> > work 100% reliably because whatever cookie you put in could have been
> > there before by chance.
>
> I wrote a test program (fill an area with zeroes, fxsave, inspect
> reserved fields, then fill it with ones, fxsave, inspect again),
> and all processors appear to just not write anything to the reserved
> fields after the last xmm register. (Tested on an old Mobile Athlon64,
> Opteron 280, P4 Xeon, Pentium-D, and C2 Xeon E5345.)
>
> So the question now is what if anything has the Linux kernel written
> to those reserved fields. (Looking..) Hmm, signal delivery on x86-64
> seems to do fxsave directly to the fxsave area in the user's sigframe,
> which would imply that the reserved fields have unpredictable values.
>
OK, so that's not a usable path unless we can find some area in the
existing data set to put a flag. Groan.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists