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. > The second problem occurs when the maximum physical address width that KVM > reports to the VM is different than the real one. Assume the real one is > greater than the reported one (which in KVM is not greater than 40). In RHEL we patched QEMU to report the host physical address width in 0x80000008. This is less than perfect when you involve migration, which is why it's not upstream, but it avoids the problem you are reporting. > In this > case, the VM might expect exceptions when PTE bits which are higher than the > maximum (reported) address width are set, and it would not get such > exceptions. This problem can easily be experienced by small change to the > existing KVM unit-tests. > > There are many variants to this problem, and the only solution which I > consider complete is to report to the VM the maximum (52) physical address > width to the VM, configure the VM to exit on #PF with reserved-bit > error-codes, and then emulate these faulting instructions. Not even that would be a definitive solution. If the guest tries to map RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR, you would get EPT misconfiguration vmexits. I think there is no way to emulate physical address width correctly, except by disabling EPT. Paolo -- 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
