All of lore.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 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.