All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi.kivity@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	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: Mon, 09 Mar 2015 19:08:44 +0200	[thread overview]
Message-ID: <54FDD39C.9060908@gmail.com> (raw)
In-Reply-To: <54F58471.7020906@redhat.com>

On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>> 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.
>

Is the issue emulating a higher MAXPHYADDR on the guest than is 
available on the host? I don't think there's any need to support that.

Emulating a lower setting on the guest than is available on the host is, 
I think, desirable. Whether it would work depends on the relative 
priority of EPT misconfiguration exits vs. page table permission faults.

  parent reply	other threads:[~2015-03-09 17:08 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
2015-03-03 10:18   ` Nadav Amit
2015-03-03 14:31     ` Radim Krčmář
2015-03-09 17:08   ` Avi Kivity [this message]
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=54FDD39C.9060908@gmail.com \
    --to=avi.kivity@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.