On Wed, Jun 02, 2021 at 12:01:11PM -0600, Alex Williamson wrote: > On Wed, 2 Jun 2021 14:35:10 -0300 > Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > > 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? > > No, this is specifically whether DMA is cache coherent to the > processor, ie. in the case of wbinvd whether the processor needs to > invalidate its cache in order to see data from DMA. I'm confused. This is x86, all DMA is cache coherent unless the device is doing something special. > > 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. > > The IOMMU tells us if DMA is cache coherent, VFIO_DMA_CC_IOMMU maps to > IOMMU_CAP_CACHE_COHERENCY for all domains within a container. And this special IOMMU mode is basically requested by the device driver, right? Because if you use this mode you have to also use special programming techniques. This smells like all the "snoop bypass" stuff from PCIE (for GPUs even) in a different guise - it is device triggered, not platform triggered behavior. Jason
