Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
From: H. Peter Anvin
Date: Mon May 19 2008 - 13:51:23 EST
Suresh Siddha wrote:
It's also wrong, since OSXSAVE indicates that the CPU can do it, not
that the kernel can.
OSXSAVE indicates the OS support and XSAVE indicates the cpu support.
Sorry, brainfart. Don't post so early in the morning.
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.
All the reserved fields at the end of fxsave format are zeroed and
presented as such to the user. If HW makes some of these fields SW available,
then we can use those (will check). If there is any scope with the
existing format it self, that will be much better.
I was thinking about what we'd really like earlier, and given a clean
slate I'd like to see a structure looking like:
struct state_ptrs {
size_t len;
struct state_foo *foo;
struct state_bar *bar;
...
};
... where len is sizeof(struct state_ptrs). This is not merely
extensible, but it's easy for userspace to massage it into whatever
format -- longer or shorter -- that it happens to know about, and it
gives a natural way for the kernel to communicate "none of this state"
by feeding a NULL pointer. So pretty much we're looking for a way to
backwards-compatible way to stash a pointer to this structure, I figure.
-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/