> From: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> > Sent: Wednesday, September 18, 2024 6:45 PM > > On Sat, Sep 14, 2024 at 08:19:46AM +0300, Zhi Wang wrote: > > On Sat, 14 Sep 2024 02:47:27 +0000 > > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > > > 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). > > I agree GHCx BIND/UNBIND been routed to QEMU, cause there are host side > cross module managements for BIND/UNBIND. E.g. IOMMUFD page table > switching, VFIO side settings that builds host side TDI context & LOCK > TDI. > > But I do support other GHCx calls between BIND/UNBIND been directly > route to TSM low-level. E.g. get device interface report, get device > certification/measurement, TDISP RUN. It is because these communications > are purely for CoCo-VM, firmware and TDI. Host is totally out of its > business and worth nothing to pass these requirements to QEMU/VFIO and > still back into TSM low-level. > sure. If VFIO is conceptually irrelevant to an operation it's certainly right to skip it.
