Re: [PATCH v19 120/130] KVM: TDX: Add a method to ignore dirty logging

Edgecombe, Rick P
2024-03-22T23:05:46Z

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.