lkml.org 
[lkml]   [2017]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
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.

\
 
 \ /
  Last update: 2017-08-01 16:56    [W:0.056 / U:0.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site