can you please elaborate? even in presence of virtualization, appropriate
cpuid bits need to be set/visible for application, for xsave/xrstor to work
I don't think it is ... it's not overkill but rather "underkill"... it's a low-performance solution but it's guaranteed to be safe in the presence of virtualization of all its various ilk. Note that you don't need to be able to *set* the format via prctl(), just *query* (get) it.
Using prctl() allows us to make this personality-dependent if we ever need to.
While restoring from the user, kernel also need to find out what layoutNo, it really doesn't: the kernel only needs to be able to read the same format as it itself wrote.
the user is passing. So it's bi-directional. I prefer the same mechanism
(using cookies/magic numbers etc inaddition to uc_flags or cpuid checks) to
interpret the fpstate for both user/kernel.
But user can potentially change the _fpstate pointer in sigcontext struct.
ARM also seem to be using similar things while extending their ucontext_t,Again, the kernel already knows the format, so it doesn't need to check.
with out other kernel interfaces to indicate the layout.
BTW, how come 32bit kernel doesn't have the X86_FXSR_MAGIC checks, while restoring
the extended fxsave data from _fpstate?
What happens with some old applications which change the _fpstate
pointer. they may or may not be fxsave aware...