2015-03-03 12:18+0200, Nadav Amit: > Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 03/03/2015 09:34, Nadav Amit wrote: > >> I got two conformance issues in x86/KVM. For the first one I have no > >> solution. For the latter, my solution is not “great”. Ideas and feedback > >> would be appreciated. > >> > >> The first problem is caused by the deprecating of FPU CS/DS in new Intel > >> CPUs. Assume the VM executes a floating point instruction in real mode (when > >> CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and > >> restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the > >> VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it > >> is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP]. > > > > I think this was analyzed a couple years ago and we decided that this bit > > was not virtualizable. > > I am fully aware of the previous reports ( https://lkml.org/lkml/2013/10/16/258 ). > > However, one might have expected the conformance problem to be fully > resolved now, since [FPU CS] and [FPU DS] are deprecated in new CPUs. > Indeed, the problem is resolved in all modes, but not in real-mode. Since we can't get the CS/DS from real FPUs, we'd have to do ugly and slow hacks to virtualize it (checking all possible changes of FPU pointers and code segments). I think that forcing the deprecation bit to guest CPUID, if set on host, would be the best compromise between correctness and sanity. -- 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