> From: Dan Williams <dan.j.williams@xxxxxxxxx> > Sent: Saturday, September 14, 2024 6:09 AM > > 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 Reading this patch appears that it's implemented this way except QEMU calls a KVM_DEV uAPI instead of going through VFIO (as Yilun suggested). > > 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. > The general practice in VFIO is to design things around userspace driver control over the device w/o assuming the existence of KVM. When VMM comes to the picture the interaction with KVM is minimized unless for functional or perf reasons. e.g. KVM needs to know whether an assigned device allows non-coherent DMA for proper cache control, or mdev/new vIOMMU object needs a reference to struct kvm, etc. sometimes frequent trap-emulates is too costly then KVM/VFIO may enable in-kernel acceleration to skip Qemu via eventfd, but in this case the slow-path via Qemu has been firstly implemented. Ideally BIND/UNBIND is not a frequent operation, so falling back to Qemu in a longer path is not a real problem. If no specific functionality or security reason for doing it in-kernel, I'm inclined to agree with Zhi here (though not about complexity).
