lkml.org 
[lkml]   [2008]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectx86: xsave/xrstor support; ucontext_t extensions
Sorry for not getting back on this for so long.

I have looked at the XSAVE architecture, and it is pretty darn hideous,
mostly because it doesn't describe itself in the absence of CPUID
information. Given that, it would have been much better if there had
been separate invocations of XSAVE for each substate region. On the
other hand, normalizing to the current CPU format is probably desirable
anyway.

I would like to make this proposal for the signal frames (again, flagged
with a uc_flags bit for RT frames):

- The SW-reserved areas at the bottom of the FXSAVE region will be used
as follows:
- A magic number (M1)
- A length pointer (L1), giving the length of the entire XSAVE region.

- At the end of the XSAVE region, i.e. at the offset given by the length
pointer, we create a secondary structure looking something like this:

- Magic number (M2)
- Descriptor count (DC)
- DC * <EBX, EAX> from CPUID leaf 0Dh
- Possibly a checksum or CRC of this structure

Note that this tail structure will always be the same on a given kernel,
so it can be pre-canned at boot time. This tail structure serves two
purposes:

- It can be used to verify against truncation of the state.
(I.e. if an XSAVE-unaware application tries to copy and save away
a state and later restore it, but only copies the first 512 bytes
and later just puts a pointer to it.)
- It can be used to verify against an alien state (saved and restored
from another CPU, or even just another kernel version with different
support.)

If there is a mismatch, we can then take appropriate action:

- No M1 or M2 signature, or L1 or DC are insane:
-> Reinitialize any non-FXSAVE state.

- M1, M2, L1, and DC make sense, but mismatch on DC or descriptor
offsets:
-> Do a region-by-region copy in of the state; reinitialize any
regions not provided.

- Mismatch on descriptor sizes:
-> Consider that region corrupt and reinitialize?

The region-by-region copy could of course be used even in the same-CPU
case, if there turns out to be a negible performance difference over
whole-block copy.

Thoughts?

-hpa



\
 
 \ /
  Last update: 2008-06-06 02:41    [W:0.208 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site