From: Paolo Bonzini <pbonzini@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>, kvm list <kvm@vger.kernel.org>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: 2 CPU Conformance Issue in KVM/x86
Date: Tue, 03 Mar 2015 10:52:49 +0100 [thread overview]
Message-ID: <54F58471.7020906@redhat.com> (raw)
In-Reply-To: <A6F671BC-983C-4005-87E9-FCC68DEF0D30@gmail.com>
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
next prev parent reply other threads:[~2015-03-03 9:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 8:34 2 CPU Conformance Issue in KVM/x86 Nadav Amit
2015-03-03 9:52 ` Paolo Bonzini [this message]
2015-03-03 10:18 ` Nadav Amit
2015-03-03 14:31 ` Radim Krčmář
2015-03-09 17:08 ` Avi Kivity
2015-03-09 17:51 ` Nadav Amit
2015-03-09 18:23 ` Avi Kivity
2015-03-09 19:07 ` Nadav Amit
2015-03-09 19:19 ` Avi Kivity
2015-03-09 19:38 ` Paolo Bonzini
2015-03-09 19:49 ` Avi Kivity
2015-03-10 10:47 ` Paolo Bonzini
2015-03-10 20:38 ` Avi Kivity
2015-03-09 19:33 ` Paolo Bonzini
2015-03-09 19:50 ` Avi Kivity
2015-03-10 10:44 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F58471.7020906@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=nadav.amit@gmail.com \
--cc=rkrcmar@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox