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. Paolo
