> On 23 Aug 2019, at 17:44, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Fri, Aug 23, 2019 at 04:47:14PM +0300, Liran Alon wrote: >> >> >>> On 23 Aug 2019, at 4:07, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: >>> >>> Add an explicit emulation type for forced #UD emulation and use it to >>> detect that KVM should unconditionally inject a #UD instead of falling >>> into its standard emulation failure handling. >>> >>> Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> >> >> The name "forced emulation on #UD" is not clear to me. >> >> If I understand correctly, EMULTYPE_TRAP_UD is currently used to indicate >> that in case the x86 emulator fails to decode instruction, the caller would >> like the x86 emulator to fail early such that it can handle this condition >> properly. Thus, I would rename it EMULTYPE_TRAP_DECODE_FAILURE. > > EMULTYPE_TRAP_UD is used when KVM intercepts a #UD from hardware. KVM > only emulates select instructions in this case in order to minmize the > emulator attack surface, e.g.: > > if (unlikely(ctxt->ud) && likely(!(ctxt->d & EmulateOnUD))) > return EMULATION_FAILED; > > To enable testing of the emulator, KVM recognizes a special "opcode" that > triggers full emulation on #UD, e.g. ctxt->ud is false when the #UD was > triggered with the magic prefix. The prefix is only recognized when the > module param force_emulation_prefix is toggled on, hence the name > EMULTYPE_TRAP_UD_FORCED. Ah-ha. This makes sense. Thanks for the explanation. I would say it’s worth putting a comment in it in code… > >> But this new flag seems to do the same. So I’m left confused. I’m probably >> missing something trivial here.
