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.
next prev parent 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