On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote:
quoted text
> > 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.

We can use some of these fields, to represent the extended state
presence with a cookie, save area size, mask of the state
stored. If needed, we can include the start address of the fpstate pointer
(also as part of the cookie), so that we can detect the situation,
where apps are just memcopying sizeof(struct _fpstate) from the fpstate
pointer (but not aware of the extended state).

we don't need any ucontext_t extensions any more and just
use the fpstate pointer to indicate the extended state aswell, right?

In addition, we need to make sure that for 32bit non-rt sigframes, we
don't modify the extramask[] offset.

thanks,
suresh
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/