On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: > > In that case we use a 32-bit operand size [F]XRSTOR, and hence > the upper halves get treated as selectors, and the offsets get > zero-extended from the low halves, i.e. we preserve even more > state for such a 64-bit environment now too (albeit I doubt any > 64-bit code actually cares) No, it does *not* preserve "more state". It preserves *less* state, because the upper 32 bits of rip are now corrupted. Any 64-bit application that actually looks at the FP rip/rdp fields now get the WRONG VALUES. The "upper bits zero" mode may be used just for JIT'ed code, for example. It doesn't mean that you'd never have full 64-bit addresses, so writing to the top half of the register *corrupts* that information, because the top half bits are still relevant in general, even if perhaps _one_ particular floating point exception happened with the bits clear. Now anybody looking at the FP state on the stack gets the wrong results. More bits set is *not* "more state", when those bits are wrong. Linus -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html