Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions

[Mikael Pettersson <mikpe@it.uu.se>]

H. Peter Anvin writes:
 > Suresh Siddha wrote:
 > >>
 > >> An ugly workaround could be to start clearing one of these fields,
 > >> and say that the data there is only valid for kernels >= 2.6.26.
 > >> (I said it was ugly...)
 > >>
 > >> Or we go back to stashing a flag in uc_flags (which is kosher),
 > >> and try to figure out how to mark non-rt sigframes.
 > > 
 > > This issue of not-zeroing, is present in only 64bit kernels and for 64bit apps,
 > > right?
 > > 
 > > 64bit app signal handling uses only rt_frame, so we can add an uc_flag for
 > > them and for 32bit apps, kernel was always zero'ing the reserved bits
 > > at the end of _fpstate.
 > > 
 > > In short, for non-rt frames, they can check the reserved bits at the end
 > > of fpstate frame and for rt-frames (perhaps even for 32bit rt frame handling)
 > > apps can check for uc_flag aswell, for extended state presence. Is this
 > > good enough?
 > > 
 > 
 > Okay, trying to close on this :)
 > 
 > I would suggest using the uc_flag for the rt frames, and simply rely on 
 > the OSXSAVE flag for non-rt signal frames.  It a rather sucky approach 
 > (as previously discussed), but since any sane user of these fields (as 
 > opposed to just relying on the kernel to save/restore) should use the 
 > SIGINFO frames, I don't see a problem *as long as it's possible to get 
 > the information* -- any solution which demands performance should just 
 > turn on SIGINFO and be happy.

I don't have the luxury to unconditionally change non-rt signal delivery
to rt signal delivery, but using uc_flags plus OSXSAVE or prctl() to
announce these layout changes would work for us. Of course, any existing
sigframe mangling (as opposed to just reading it) code must be updated
to avoid breakage, but that's unavoidable.

 > The biggest potential problem with this that I see is that relying on 
 > CPUID can mess with certain virtualization solutions.  Another option to 
 > accomplish the same thing would be to have a system call (preferrably a 
 > prctl, since it is at least in theory personality-dependent) to query 
 > what information is included in the fpstate data - since it will always 
 > be the same for any particular kernel.
 > 
 > Thoughts?

Ok for me.

/Mikael