From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: 2 CPU Conformance Issue in KVM/x86 Date: Tue, 03 Mar 2015 10:52:49 +0100 Message-ID: <54F58471.7020906@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= To: Nadav Amit , kvm list Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45081 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755811AbbCCJw4 (ORCPT ); Tue, 3 Mar 2015 04:52:56 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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 =E2=80=9Cgreat=E2=80=9D.= Ideas and feedback > would be appreciated. >=20 > The first problem is caused by the deprecating of FPU CS/DS in new In= tel > CPUs. Assume the VM executes a floating point instruction in real mod= e (when > CS !=3D 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, s= ince 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 tha= t 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, whic= h 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 t= han 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. >=20 > 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 ad= dress > 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 ma= p 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