Messages in this thread | | | Date | Mon, 19 May 2008 10:45:37 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions |
| |
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
| |