On Mon, Oct 16, 2023 at 08:26:25AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Friday, October 13, 2023 10:06 PM > > > > On Fri, Oct 13, 2023 at 07:13:34AM +0000, Tian, Kevin wrote: > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > > Sent: Friday, October 13, 2023 3:10 AM > > > > > > > > Also, we probably should feed enforce_cache_coherency through the > > > > alloc_hwpt uapi and not try to autodetect it.. > > > > > > > > > > In the past we had a long discussion about this with the conclusion > > > that user opt is the ideal model but it's fine to stay with autodetect > > > and existing vfio/kvm contract for coherency detection until we > > > see a real demand for user opt. > > > > > > Is there anything new which changes your mind to have user opt now? > > > > I guess, I was just looking at the complexity it brings to keep that > > working. > > > > vfio_file_enforced_coherent() currently just looks at device_iommu_capable() > and can be called before attach, assuming an autodetect model. > > moving away from autodetect would need a new contract which I hesitate > to bother with at this point. I think that is fine, we are not enabling new behaviors where qemu can directly control the wbinvd support. If we want to do that it can be done more directly. If the vmm sees a coherent device and does not turn on enforced coherency then it will get a broken wbinvd and be sad. Since this is all in the userspace vt-d iommu driver, it can just do the right thing anyhow. Jason
