linux-kernel.vger.kernel.org archive mirror
 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 18:33:44 +0200	[thread overview]
Message-ID: <20140902163344.GB16722@suse.de> (raw)
In-Reply-To: <1409670830-14544-3-git-send-email-pbonzini@redhat.com>

Ah, here you add emulation of these bits.

On Tue, Sep 02, 2014 at 05:13:48PM +0200, Paolo Bonzini wrote:
> This is similar to what the EPT code does with the exit qualification.
> This allows the guest to see a valid value for bits 33:32.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  arch/x86/kvm/paging_tmpl.h |  6 ++++++
>  arch/x86/kvm/svm.c         | 26 ++++++++++++++++++++++----
>  2 files changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
> index 410776528265..99d4c4e836a0 100644
> --- a/arch/x86/kvm/paging_tmpl.h
> +++ b/arch/x86/kvm/paging_tmpl.h
> @@ -322,8 +322,14 @@ retry_walk:
>  
>  		real_gfn = mmu->translate_gpa(vcpu, gfn_to_gpa(table_gfn),
>  					      PFERR_USER_MASK|PFERR_WRITE_MASK);
> +
> +		/*
> +		 * Can this happen (except if the guest is playing TOCTTOU games)?
> +		 * We should have gotten a nested page fault on table_gfn instead.
> +		 */

Comment is true, but doesn't make the check below obsolete, no?

>  		if (unlikely(real_gfn == UNMAPPED_GVA))
>  			goto error;
> @@ -1974,10 +1974,28 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu *vcpu,
>  {
>  	struct vcpu_svm *svm = to_svm(vcpu);
>  
> -	svm->vmcb->control.exit_code = SVM_EXIT_NPF;
> -	svm->vmcb->control.exit_code_hi = 0;
> -	svm->vmcb->control.exit_info_1 = fault->error_code;
> -	svm->vmcb->control.exit_info_2 = fault->address;
> +	/*
> +	 * We can keep the value that the processor stored in the VMCB,
> +	 * but make up something sensible if we hit the WARN.
> +	 */
> +	if (WARN_ON(svm->vmcb->control.exit_code != SVM_EXIT_NPF)) {
> +		svm->vmcb->control.exit_code = SVM_EXIT_NPF;
> +		svm->vmcb->control.exit_code_hi = 0;
> +		svm->vmcb->control.exit_info_1 = (1ULL << 32);
> +		svm->vmcb->control.exit_info_2 = fault->address;
> +	}

Its been a while since I looked into this, but is an injected NPF exit
always the result of a real NPF exit? 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, maybe
causing NPF faults to be injected. In this case an IOIO exit would cause
an injected NPF exit for L1.


	Joerg


  reply	other threads:[~2014-09-02 16:33 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 [this message]
2014-09-02 16:46     ` Paolo Bonzini
2014-09-02 17:01       ` Paolo Bonzini
2014-09-02 17:01       ` Joerg Roedel
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=20140902163344.GB16722@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;
as well as URLs for NNTP newsgroup(s).