On Wed, Jun 02, 2021 at 11:11:17AM -0600, Alex Williamson wrote: > > > > present and be able to test if DMA for that device is cache > > > > coherent. > > > > Why is this such a strong linkage to VFIO and not just a 'hey kvm > > emulate wbinvd' flag from qemu? > > IIRC, wbinvd has host implications, a malicious user could tell KVM to > emulate wbinvd then run the op in a loop and induce a disproportionate > load on the system. We therefore wanted a way that it would only be > enabled when required. I think the non-coherentness is vfio_device specific? eg a specific device will decide if it is coherent or not? If yes I'd recast this to call kvm_arch_register_noncoherent_dma() from the VFIO_GROUP_NOTIFY_SET_KVM in the struct vfio_device implementation and not link it through the IOMMU. If userspace is telling the vfio_device to be non-coherent or not then it can call kvm_arch_register_noncoherent_dma() or not based on that signal. > > It kind of looks like the other main point is to generate the > > VFIO_GROUP_NOTIFY_SET_KVM which is being used by two VFIO drivers to > > connect back to the kvm data > > > > But that seems like it would have been better handled with some IOCTL > > on the vfio_device fd to import the KVM to the driver not this > > roundabout way? > > Then QEMU would need to know which drivers require KVM knowledge? This > allowed transparent backwards compatibility with userspace. Thanks, I'd just blindly fire a generic 'hey here is your KVM FD' into every VFIO device. The backwards compat angle is reasonable enough though. So those two don't sound so bad, don't know about PPC, but David seem optimistic A basic idea is to remove the iommu stuff from the kvm connection so that the scope of the iommu related rework is contained to vfio Jason
