Zhi Wang wrote: > On Fri, 23 Aug 2024 23:21:25 +1000 > Alexey Kardashevskiy <aik@xxxxxxx> wrote: > > > The SEV TIO spec defines a new TIO_GUEST_MESSAGE message to > > provide a secure communication channel between a SNP VM and > > the PSP. > > > > The defined messages provide way to read TDI info and do secure > > MMIO/DMA setup. > > > > On top of this, GHCB defines an extension to return certificates/ > > measurements/report and TDI run status to the VM. > > > > The TIO_GUEST_MESSAGE handler also checks if a specific TDI bound > > to the VM and exits the KVM to allow the userspace to bind it. > > > > Out of curiosity, do we have to handle the TDI bind/unbind in the kernel > space? It seems we are get the relationship between modules more > complicated. What is the design concern that letting QEMU to handle the > TDI bind/unbind message, because QEMU can talk to VFIO/KVM and also TSM. Hmm, the flow I have in mind is: Guest GHCx(BIND) => KVM => TSM GHCx handler => VFIO state update + TSM low-level BIND vs this: (if I undertand your question correctly?) Guest GHCx(BIND) => KVM => TSM GHCx handler => QEMU => VFIO => TSM low-level BIND Why exit to QEMU only to turn around and call back into the kernel? VFIO should already have the context from establishing the vPCI device as "bind-capable" at setup time. Maybe I misunderstood your complication concern?
