Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
From: H. Peter Anvin
Date: Mon May 19 2008 - 12:39:44 EST
Mikael Pettersson wrote:
My problem with the OSXAVE flag is that it's a very indirect way of
communicating the layout of sigframes and sigcontexts. These structures
should, if at all possible, be self-describing. A single flag bit in
the sigcontext could handle both structures (since a sigframe always
includes a sigcontext).
It's also wrong, since OSXSAVE indicates that the CPU can do it, not
that the kernel can.
struct _fpstate has a 'magic' field which distinguishes x87-only
from x87+FXSR structs. Could that field also be used to indicate XSAVE?
I don't think we can use the existing 'magic' field.
Hmm, right now it seems this field has a de-facto ABI of being
either 0xffff (plain) or 0x0000 (fxsr). Using other values would
confuse at least one application I know of. Sad.
Well, arguably it is the right thing to use since we're talking about a
new format. The difference is that the new format *does* extend
backwards to match the old format.
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.
All we need is a single field -- a single byte -- reserved indefinitely
for software use. Existing FXSAVE kernels will have set it to zero.
There might be fields the existing FXSAVE format which can be equally
abused, even. I will do some looking.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/