public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, agraf@suse.de,
	valentine.sinitsyn@gmail.com, jan.kiszka@siemens.com,
	gleb@cloudius-systems.com, avi@cloudius-systems.com
Subject: Re: [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the guest
Date: Tue, 2 Sep 2014 19:01:30 +0200	[thread overview]
Message-ID: <20140902170130.GC16722@suse.de> (raw)
In-Reply-To: <5405F44E.7090803@redhat.com>

On Tue, Sep 02, 2014 at 06:46:06PM +0200, Paolo Bonzini wrote:
> Il 02/09/2014 18:33, Joerg Roedel ha scritto:
> > Comment is true, but doesn't make the check below obsolete, no?
> 
> No, it doesn't.  I'll rewrite it as
> 
> 	/*
> 	 * This cannot happen unless the guest is playing TOCTTOU games,
> 	 * because we would have gotten a nested page fault on table_gfn
> 	 * instead.  If this happens, the exit qualification / exit info
> 	 * field will incorrectly have "guest page access" as the
> 	 * nested page fault's cause, instead of "guest page structure
> 	 * access".
> 	 */

Sounds good.

> > Its been a while since I looked into this, but is an injected NPF exit
> > always the result of a real NPF exit?
> 
> I think so, but that's why I CCed you. :)
> 
> > How about an io-port emulated on
> > L1 but passed through to L2 by the nested hypervisor. On emulation of
> > INS or OUTS, KVM would need to read/write to an L2 address space,
> 
> It would need to read/write to *L1* (that's where the VMCB's IOIO map
> lies), which could result into a regular page fault injected into L1.

Hmm, INS and OUTS read/write to a virtual memory location, right? So if
we have an io-port intercepted by bare-metal KVM but not by the L1
hypervisor, and the L2 guest accesses this io-port, bare-metal KVM would
get an IOIO exit it has to emulate itself (it can't inject an IOIO exit
to L1 anyway, since L1 does not intercept the io-port).

During emulation the bare-metal KVM would read/write at an L2 virtual
address, because that is the context the instruction is executed in.
And while resolving this L2 virtual address, an NPF fault could be
detected that needs to be injected into the L1 hypervisor, right?



	Joerg

  parent reply	other threads:[~2014-09-02 17:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 15:13 [PATCH 0/4] KVM: nested x86: nested page faults fixes Paolo Bonzini
2014-09-02 15:13 ` [PATCH 1/4] KVM: x86: reserve bit 8 of non-leaf PDPEs and PML4Es in 64-bit mode on AMD Paolo Bonzini
2014-09-02 15:13 ` [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the guest Paolo Bonzini
2014-09-02 16:33   ` Joerg Roedel
2014-09-02 16:46     ` Paolo Bonzini
2014-09-02 17:01       ` Paolo Bonzini
2014-09-02 17:01       ` Joerg Roedel [this message]
2014-09-02 17:47       ` Avi Kivity
2014-09-02 15:13 ` [PATCH 3/4] KVM: x86: inject nested page faults on emulated instructions Paolo Bonzini
2014-09-04  7:02   ` Gleb Natapov
2014-09-04 14:12     ` Paolo Bonzini
2014-09-04 15:05       ` Gleb Natapov
2014-09-04 17:17         ` Paolo Bonzini
2014-09-04 17:44         ` Paolo Bonzini
2014-09-05  9:47           ` Gleb Natapov
2014-09-02 15:13 ` [PATCH 4/4] KVM: x86: propagate exception from permission checks on the nested page fault Paolo Bonzini
2014-09-02 16:02 ` [PATCH 0/4] KVM: nested x86: nested page faults fixes Valentine Sinitsyn
2014-09-02 16:56   ` 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=20140902170130.GC16722@suse.de \
    --to=jroedel@suse.de \
    --cc=agraf@suse.de \
    --cc=avi@cloudius-systems.com \
    --cc=gleb@cloudius-systems.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=valentine.sinitsyn@gmail.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