Re: [PATCH v5 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
From: Radim KrÄmÃÅ
Date: Tue Aug 01 2017 - 10:55:43 EST
2017-08-01 13:40+0200, David Hildenbrand:
> On 31.07.2017 21:32, Bandan Das wrote:
> > David Hildenbrand <david@xxxxxxxxxx> 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.