On 06/11/2017 14:25, Liran Alon wrote: >> What is the caller of x86_emulate_instruction that you are interested >> in? #UD is not affected, because emulation_type has EMULTYPE_TRAP_UD >> set and therefore x86_emulate_instruction exits before invoking >> handle_emulation_failure. >> > I think this patch is still correct from a number of reasons: > > 1) If I understand the code correctly, semantically it doesn't make > sense to fill kvm_run struct without exiting to user-mode. Therefore, if > emulator filled kvm_run, it makes sense that it needs to return > EMULATE_USER_EXIT. > > 2) EMULTYPE_TRAP_UD only causes the emulator to return EMULATE_FAIL in > case emulation fails on instruction decoding. However, consider a case > where #UD intercept happens on a valid instruction (such as VMMCALL AMD > opcode on physical Intel CPU). In that case, instruction decoding > doesn't fail but we could still fail on instruction emulation at > x86_emulate_insn(). In this case, EMULTYPE_TRAP_UD flag is not > considered anymore and failure will reach handle_emulation_failure(). (1) is true, but (2) more or less answers my question. So Reviewed-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > 3) We have another KVM commits series (not upstream yet) that adds > intercept on #GP which calls the x86 emulator. This is done to allow > access to I/O ports even though they aren't allowed via guest's TSS I/O > permissions bitmap. vmport?... :) Paolo
