On Fri, 2024-03-22 at 15:57 -0700, Isaku Yamahata wrote: > > KVM fault handler, kvm_mmu_page_fault(), is the caller into the > > emulation, > > It should skip the emulation. > > > > As the second guard, x86_emulate_instruction(), calls > > check_emulate_instruction() callback to check if the emulation > > can/should be > > done. TDX callback can return it as X86EMUL_UNHANDLEABLE. Then, > > the flow goes > > to user space as error. I'll update the > > vt_check_emulate_instruction(). > > Oops. It was wrong. It should be X86EMUL_RETRY_INSTR. RETRY_INSTR > means, let > vcpu execute the intrusion again, UNHANDLEABLE means, emulator can't > emulate, > inject exception or give up with KVM_EXIT_INTERNAL_ERROR. > > For TDX, we'd like to inject #VE to the guest so that the guest #VE > handler > can issue TDG.VP.VMCALL<MMIO>. The default non-present sept value > has > #VE suppress bit set. As first step, EPT violation occurs. then KVM > sets > up mmio_spte with #VE suppress bit cleared. Then X86EMUL_RETRY_INSTR > tells > kvm to resume vcpu to inject #VE. Ah, so in a normal VM it would: - get ept violation for no memslot - setup MMIO PTE for later - go ahead and head to the emulator anyway instead of waiting to refault In TDX, it could skip the last step and head right to the guest, but instead if heads to the emulator and gets told to retry there. It's a good solution in that there is already an way to cleanly insert logic at check_emulate_instruction(). Otherwise we would need to add another check somewhere to know in TDX to consider the fault resolved. I was initially thinking if it gets anywhere near the emulator things have gone wrong and we are missing something. The downside is that we can't find those issues. If something tries to use the emulator it will just fault in a loop instead of exiting to userspace or bugging the VM. Hmm.
