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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at