From: Bandan Das <bsd@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com,
linux-kernel@vger.kernel.org, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor
Date: Thu, 13 Jul 2017 13:08:49 -0400 [thread overview]
Message-ID: <jpgtw2g463i.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <8c58f57d-091f-103d-5d8c-fc49b9d00e13@redhat.com> (David Hildenbrand's message of "Thu, 13 Jul 2017 17:39:48 +0200")
David Hildenbrand <david@redhat.com> writes:
>>>> + /*
>>>> + * If the (L2) guest does a vmfunc to the currently
>>>> + * active ept pointer, we don't have to do anything else
>>>> + */
>>>> + if (vmcs12->ept_pointer != address) {
>>>> + if (address >> cpuid_maxphyaddr(vcpu) ||
>>>> + !IS_ALIGNED(address, 4096))
>>>
>>> Couldn't the pfn still be invalid and make kvm_mmu_reload() fail?
>>> (triggering a KVM_REQ_TRIPLE_FAULT)
>>
>> If there's a triple fault, I think it's a good idea to inject it
>> back. Basically, there's no need to take care of damage control
>> that L1 is intentionally doing.
>
> I quickly rushed over the massive amount of comments. Sounds like you'll
> be preparing a v5. Would be great if you could add some comments that
> were the result of this discussion (for parts that are not that obvious
> - triple faults) - thanks!
Will do. Basically, we agreed that we don't need to do anything with mmu_reload() faillures
because the invalid eptp that mmu_unload will write to root_hpa will result in an ept
violation.
Bandan
prev parent reply other threads:[~2017-07-13 17:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 20:49 [PATCH v4 0/3] Expose VMFUNC to the nested hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 1/3] KVM: vmx: Enable VMFUNCs Bandan Das
2017-07-10 20:49 ` [PATCH v4 2/3] KVM: nVMX: Enable VMFUNC for the L1 hypervisor Bandan Das
2017-07-10 20:49 ` [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching " Bandan Das
2017-07-11 7:51 ` David Hildenbrand
2017-07-11 8:39 ` Paolo Bonzini
2017-07-11 13:52 ` Radim Krčmář
2017-07-11 18:05 ` Bandan Das
2017-07-11 19:12 ` Radim Krčmář
2017-07-11 19:34 ` Bandan Das
2017-07-11 17:58 ` Bandan Das
2017-07-11 18:22 ` Jim Mattson
2017-07-11 18:35 ` Bandan Das
2017-07-11 19:13 ` Radim Krčmář
2017-07-11 19:38 ` Bandan Das
2017-07-11 20:22 ` Radim Krčmář
2017-07-11 20:45 ` Bandan Das
2017-07-12 13:41 ` Radim Krčmář
2017-07-12 18:04 ` Bandan Das
2017-07-11 18:24 ` Bandan Das
2017-07-11 19:32 ` Radim Krčmář
2017-07-11 19:50 ` Bandan Das
2017-07-11 20:21 ` Radim Krčmář
2017-07-11 20:34 ` Bandan Das
2017-07-11 20:45 ` Radim Krčmář
2017-07-11 21:08 ` Bandan Das
2017-07-12 13:24 ` Radim Krčmář
2017-07-12 18:11 ` Bandan Das
2017-07-12 19:18 ` Radim Krčmář
2017-07-17 17:58 ` Bandan Das
2017-07-19 9:30 ` Radim Krčmář
2017-07-19 17:54 ` Bandan Das
2017-07-13 15:39 ` David Hildenbrand
2017-07-13 17:08 ` Bandan Das [this message]
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=jpgtw2g463i.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@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.