All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Bandan Das <bsd@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
	kvm@vger.kernel.org, pbonzini@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
Date: Tue, 11 Jul 2017 21:32:36 +0200	[thread overview]
Message-ID: <20170711193235.GE3326@potion> (raw)
In-Reply-To: <jpg1spmsugn.fsf@linux.bootlegged.copy>

2017-07-11 14:24-0400, Bandan Das:
> Bandan Das <bsd@redhat.com> writes:
> > If there's a triple fault, I think it's a good idea to inject it
> > back. Basically, there's no need to take care of damage control
> > that L1 is intentionally doing.
> >
> >>> +			goto fail;
> >>> +		kvm_mmu_unload(vcpu);
> >>> +		vmcs12->ept_pointer = address;
> >>> +		kvm_mmu_reload(vcpu);
> >>
> >> I was thinking about something like this:
> >>
> >> kvm_mmu_unload(vcpu);
> >> old = vmcs12->ept_pointer;
> >> vmcs12->ept_pointer = address;
> >> if (kvm_mmu_reload(vcpu)) {
> >> 	/* pointer invalid, restore previous state */
> >> 	kvm_clear_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> >> 	vmcs12->ept_pointer = old;
> >> 	kvm_mmu_reload(vcpu);
> >> 	goto fail;
> >> }
> >>
> >> The you can inherit the checks from mmu_check_root().
> 
> Actually, thinking about this a bit more, I agree with you. Any fault
> with a vmfunc operation should end with a vmfunc vmexit, so this
> is a good thing to have. Thank you for this idea! :)

SDM says

  IF tent_EPTP is not a valid EPTP value (would cause VM entry to fail
  if in EPTP) THEN VMexit;

and no other mentions of a VM exit, so I think that the VM exit happens
only under these conditions:

  — The EPT memory type (bits 2:0) must be a value supported by the
    processor as indicated in the IA32_VMX_EPT_VPID_CAP MSR (see
    Appendix A.10).
  — Bits 5:3 (1 less than the EPT page-walk length) must be 3, indicating
    an EPT page-walk length of 4; see Section 28.2.2.
  — Bit 6 (enable bit for accessed and dirty flags for EPT) must be 0 if
    bit 21 of the IA32_VMX_EPT_VPID_CAP MSR (see Appendix A.10) is read
    as 0, indicating that the processor does not support accessed and
    dirty flags for EPT.
  — Reserved bits 11:7 and 63:N (where N is the processor’s
    physical-address width) must all be 0.

And it looks like we need parts of nested_ept_init_mmu_context() to
properly handle VMX_EPT_AD_ENABLE_BIT.

The KVM_REQ_TRIPLE_FAULT can be handled by kvm_mmu_reload in vcpu_run if
we just invalidate the MMU.

  reply	other threads:[~2017-07-11 19:32 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10 20:49 [PATCH v4 0/3] Expose VMFUNC to the nested hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 1/3] KVM: vmx: Enable VMFUNCs Bandan Das
2017-07-10 20:49 ` [PATCH v4 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching " Bandan Das
2017-07-11  7:51   ` David Hildenbrand
2017-07-11  8:39     ` Paolo Bonzini
2017-07-11 13:52     ` Radim Krčmář
2017-07-11 18:05       ` Bandan Das
2017-07-11 19:12         ` Radim Krčmář
2017-07-11 19:34           ` Bandan Das
2017-07-11 17:58     ` Bandan Das
2017-07-11 18:22       ` Jim Mattson
2017-07-11 18:35         ` Bandan Das
2017-07-11 19:13           ` Radim Krčmář
2017-07-11 19:38             ` Bandan Das
2017-07-11 20:22               ` Radim Krčmář
2017-07-11 20:45                 ` Bandan Das
2017-07-12 13:41                   ` Radim Krčmář
2017-07-12 18:04                     ` Bandan Das
2017-07-11 18:24       ` Bandan Das
2017-07-11 19:32         ` Radim Krčmář [this message]
2017-07-11 19:50           ` Bandan Das
2017-07-11 20:21             ` Radim Krčmář
2017-07-11 20:34               ` Bandan Das
2017-07-11 20:45                 ` Radim Krčmář
2017-07-11 21:08                   ` Bandan Das
2017-07-12 13:24                     ` Radim Krčmář
2017-07-12 18:11                       ` Bandan Das
2017-07-12 19:18                         ` Radim Krčmář
2017-07-17 17:58               ` Bandan Das
2017-07-19  9:30                 ` Radim Krčmář
2017-07-19 17:54                   ` Bandan Das
2017-07-13 15:39       ` David Hildenbrand
2017-07-13 17:08         ` Bandan Das

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=20170711193235.GE3326@potion \
    --to=rkrcmar@redhat.com \
    --cc=bsd@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@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.