lkml.org 
[lkml]   [2008]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-05-19 19:53    [W:0.070 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site