public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Bandan Das <bsd@redhat.com>,
	kvm@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
Date: Tue, 1 Aug 2017 16:55:31 +0200	[thread overview]
Message-ID: <20170801145531.GB302@flask> (raw)
In-Reply-To: <fd35cbc5-4d5e-002a-e269-667caa0d2ac2@redhat.com>

2017-08-01 13:40+0200, David Hildenbrand:
> On 31.07.2017 21:32, Bandan Das wrote:
> > David Hildenbrand <david@redhat.com> writes:
> >>> +	/* AD, if set, should be supported */
> >>> +	if ((address & VMX_EPT_AD_ENABLE_BIT)) {
> >>> +		if (!enable_ept_ad_bits)
> >>> +			return false;
> >>> +		mmu->ept_ad = true;
> >>> +	} else
> >>> +		mmu->ept_ad = false;

This block should also set the mmu->base_role.ad_disabled.

(The idea being that things should be done as if the EPTP was set during
 a VM entry.  The only notable difference is that we do not reload
 PDPTRS.)

> >> I wouldn't expect a "check" function to modify the mmu. Can you move
> >> modifying the mmu outside of this function (leaving the
> >> enable_ept_ad_bits check in place)? (and maybe even set mmu->ept_ad
> >> _after_ the kvm_mmu_unload(vcpu)?, just when setting vmcs12->ept_pointer?)
> >>
> > 
> > Well, the correct thing to do is have a wrapper around it in mmu.c
> > without directly calling here and also call this function before
> > nested_mmu is initialized. I am working on a separate patch for this btw.
> 
> Sounds good. Also thought that encapsulating this might be a good option.

Seconded. :)

> >>> +	if (vmcs12->ept_pointer != address) {
> >>> +		if (!check_ept_address_valid(vcpu, address)) {
> >>> +			kunmap(page);
> >>> +			nested_release_page_clean(page);
> >>> +			return 1;
> >>> +		}
> >>> +		kvm_mmu_unload(vcpu);
> >>> +		vmcs12->ept_pointer = address;
> >>> +		/*
> >>> +		 * TODO: Check what's the correct approach in case
> >>> +		 * mmu reload fails. Currently, we just let the next
> >>> +		 * reload potentially fail
> >>> +		 */
> >>> +		kvm_mmu_reload(vcpu);
> >>
> >> So, what actually happens if this generates a tripple fault? I guess we
> >> will kill the (nested) hypervisor?
> > 
> > Yes. Not sure what's the right thing to do is though...

Right, we even drop kvm_mmu_reload() here for now and let the one in
vcpu_enter_guest() take care of the thing.

> Wonder what happens on real hardware.

This operation cannot fail or real hardware.  All addresses within the
physical address limit return something when read.  On Intel, this is a
value with all bits set (-1) and will cause an EPT misconfiguration VM
exit on the next page walk (instruction decoding).

Thanks.

  reply	other threads:[~2017-08-01 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28 19:52 [PATCH v5 0/3] Expose VMFUNC to the nested hypervisor Bandan Das
2017-07-28 19:52 ` [PATCH v5 1/3] KVM: vmx: Enable VMFUNCs Bandan Das
2017-07-28 19:52 ` [PATCH v5 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor Bandan Das
2017-07-28 19:52 ` [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching " Bandan Das
2017-07-31 11:59   ` David Hildenbrand
2017-07-31 19:32     ` Bandan Das
2017-08-01 11:40       ` David Hildenbrand
2017-08-01 14:55         ` Radim Krčmář [this message]
2017-08-01 15:17   ` Radim Krčmář
2017-08-01 18:30     ` 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=20170801145531.GB302@flask \
    --to=rkrcmar@redhat.com \
    --cc=bsd@redhat.com \
    --cc=david@redhat.com \
    --cc=jmattson@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox