[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4832A173.6020203@firstfloor.org>
Date: Tue, 20 May 2008 12:01:23 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Suresh Siddha <suresh.b.siddha@...el.com>
CC: Mikael Pettersson <mikpe@...uu.se>, mingo@...e.hu, hpa@...or.com,
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
Suresh Siddha wrote:
> On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote:
>>> But we can
>>> use some what similar magic, if the fxsave/fxrstor give away
>>> some of the fields at the end of fxsave image (today it is reserved
>>> and ignored during fxsave/fxrstor) for software use.
>>> We can then use these fields at the end of fpstate, to indicate the presence of
>>> xstate. But this requires some architecture changes like giving
>>> away this space for SW use. We can take this to architects and
>>> see what they think.
>> If the HW doesn't store anything valuable there, we could store
>> SW flags/cookies there on signal delivery, and clear them before
>> fxrstor (unless the HW is known to ignore those fields).
>> But it depends on how forgiving the HW is.
>
> Ok. CPU folks are planning to make some of the bytes at the end of fxsave
> image, SW usable.
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 don't see anything in the SDM guaranteeing zeroing.
-Andi
--
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