On 5/24/2017 4:43 AM, Paolo Bonzini wrote:
On 23/05/2017 18:34, Andy Lutomirski wrote:
Using MTF is also a little bit tricky, as when we turn on MTF VMEXIT upon
ENCLS VMEXIT, the MTF won't be absolutely pending at end of that ENCLS. For
example, MTF may be pending at end of interrupt (cannot recall exactly) if
event is pending during VMENTRY from ENCLS VMEXIT. Therefore we have to do
additional thing to check whether this MTF VMEXIT really happens after ENCLS
run (step 3 above). And depending on what we need to do, we may need to
check whether ENCLS succeeded or not in guest, which is also tricky, as
ENCLS can fail in either setting error code in RAX, or generating #GP or #UD
(step 4 above). We may still need to do gva->gpa->hpa, ex, in order to
locate EPC/SECS page and update status, depending on the purpose of trapping
ENCLS.
I think there are some issues here.
First, you're making a big assumption that, when you resume the guest
with MTF set, the instruction that gets executed is still
ENCLS[EINIT]. That's not guaranteed as is -- you could race against
another vCPU that changes the instruction, the instruction could be in
IO space, host userspace could be messing with you, etc. Second, I
don't think there's any precedent at all in KVM for doing this.
Third, you still need to make sure that the MSRs retain the value you
want them to have by the time ENCLS happens. I think that, by the
time you resolve all of these issues, it'll look a lot like the
pseudocode I emailed out, and MTF won't be necessary any more.
Agreed. Emulation in the host is better.
Hi Andy/Paolo,
Thanks for comments. I'll follow your suggestion in v2.
Thanks,
-Kai
Paolo
