>>> On 16.10.13 at 17:50, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > 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". So you're thinking of whenever the state gets copied out to some (user) memory block, whereas the "more state" I wrote about applies to what is stored in CPU registers. And I also said that copying the state to use memory may require extra adjustments. The question just is how to properly do that - without corrupting state in the way you validly point out, but also without losing 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. 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. Jan -- 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
