public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
	Orit Wasserman <owasserm@redhat.com>
Subject: Re: [PATCH v2] KVM: nVMX: Improve I/O exit handling
Date: Thu, 14 Feb 2013 16:44:39 +0200	[thread overview]
Message-ID: <20130214144439.GP9817@redhat.com> (raw)
In-Reply-To: <20130214135423.GA14179@fermat.math.technion.ac.il>

On Thu, Feb 14, 2013 at 03:54:23PM +0200, Nadav Har'El wrote:
> On Thu, Feb 14, 2013, Gleb Natapov wrote about "Re: [PATCH v2] KVM: nVMX: Improve I/O exit handling":
> > > >> Not sure how to map a failure on real HW behaviour. I guess it's best to
> > > > Exit to L1 with nested_vmx_failValid() may be?
> > > 
> > > To my understanding, nested_vmx_failValid/Invalid are related to errors
> > > directly related to vm instruction execution. This one is triggered by
> > > the guest later on.
> > > 
> > You are right. We need some kind of error vmexit here, but nothing
> > appropriate is defined by the spec, so lets just assume that exit to L1
> > is needed if we cannot read permission bitmaps.
> 
> On real hardware, note that the MSR-bitmap address specified in the VMCS
> is a physical address, so there can never be an error - if I understand
> correctly, there is no such thing as a non-existant physical address -
> reading from non-existant physical memory returns random garbage (please
> correct me if I'm wrong here!). So if I'm correct, using a non-existent
> address for an MSR-bitmap will give you an undefined behavior - not any
> sort of entry error to special type of exit.
> 
That's true for real HW. Reading from physical address outside of
physical memory will either access some random device MMIO or nothing.
Either way result is unpredictable and may hang the machine. I am fine
with killing a guest that tries to do that.

> The current code, using a random value on the stack, fits with the
> "undefined behavior" definition, but you're right the more logical
> behavior is to, indeed, always exit on the MSR access when the bitmap
> cannot be read. This will make an unreadable bitmap equivalent to no
> bitmap at all - which I think makes most sense.
Current case leaks data from host kernel, not just exhibit random
behaviour.

> 
> You're also right that this case is identical in both MSR and I/O bitmap
> cases, and should be fixed in both.
> 
> 
> -- 
> Nadav Har'El                        |       Thursday, Feb 14 2013, 4 Adar 5773
> nyh@math.technion.ac.il             |-----------------------------------------
> Phone +972-523-790466, ICQ 13349191 |A fanatic is one who can't change his
> http://nadav.harel.org.il           |mind and won't change the subject.

--
			Gleb.

  reply	other threads:[~2013-02-14 14:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-10 20:42 [PATCH] KVM: nVMX: Improve I/O exit handling Jan Kiszka
2013-02-11 10:07 ` Nadav Har'El
2013-02-11 10:16   ` Jan Kiszka
2013-02-11 11:19     ` [PATCH v2] " Jan Kiszka
2013-02-14  9:32       ` Gleb Natapov
2013-02-14 11:19         ` Jan Kiszka
2013-02-14 12:11           ` Gleb Natapov
2013-02-14 12:22             ` Jan Kiszka
2013-02-14 12:56               ` Gleb Natapov
2013-02-14 13:54                 ` Nadav Har'El
2013-02-14 14:44                   ` Gleb Natapov [this message]
2013-02-14 18:46         ` [PATCH v3] " Jan Kiszka
2013-02-17  8:55           ` Gleb Natapov
2013-02-18  6:32           ` Jan Kiszka
2013-02-18  6:45             ` [PATCH v4] " Jan Kiszka
2013-02-18  8:44             ` [PATCH v3] " Gleb Natapov
2013-02-18  8:53               ` Jan Kiszka
2013-02-18  8:57                 ` Gleb Natapov
2013-02-18  9:17                   ` [PATCH v5] " Jan Kiszka
2013-02-18  9:36                     ` Gleb Natapov
2013-02-18 10:02                       ` Jan Kiszka
2013-02-18 10:21                         ` [PATCH v6] " Jan Kiszka
2013-02-18 10:32                           ` Gleb Natapov
2013-02-19  2:13                             ` Marcelo Tosatti

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=20130214144439.GP9817@redhat.com \
    --to=gleb@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=nyh@math.technion.ac.il \
    --cc=owasserm@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