Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors

[Linus Torvalds]

On Wed, Oct 16, 2013 at 9:13 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> But again - this isn't being done for ordinary 64-bit applications,
> this is only happening for KVM guests. And there not being a
> protocol for telling the caller whether a certain context hold
> 64-bit offsets or selector/offset pairs shouldn't be a reason to
> think of a solution to the problem.

So having looked at this some more, I would *really* prefer a
different solution. The overwriting of the rip/rdp data just really
annoys me.

Is there any reason to not just do it like the following instead:

 - get rid of the "word_size" thing, instead just add separate
"fcs/fos" fields (that do *not* alias with rip/rdp).

 - on 64-bit, always use 64-bit ops, exactly the way we do now

 - if the resulting rip/rpd is zero in the high bits (and we have
reason to believe the values exist at all, so X86_FEATURE_NO_FPU_SEL
and the AMD test and/or checking that they aren't zero in the low bits
too), do an *additional* fnstenv to the sstack, and then just save the
resulting fcs/fos in the non-overlapping things. Use a simple helper
function for this (that just gets called after the xsave/fxsave logic)

 - same on restore.

No games. No "this is the word-size of the thing we've saved in
memory". No overlapping "this field means one thing or another".

For signal handling, save/restore the new fop/fos thing, so that
nobody ever sees the changed format, but FP state gets correctly and
fully restored over signals too, not just kernel FP stuff.

Hmm? That would make me *much* happier, I suspect.

           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/