On Wed, Mar 05, 2025 at 02:09:09PM +1100, Alexey Kardashevskiy wrote: > > > On 1/3/25 11:32, Jason Gunthorpe wrote: > > On Thu, Feb 27, 2025 at 11:33:31AM +1100, Alexey Kardashevskiy wrote: > > > > > > > > > On 27/2/25 00:12, Jason Gunthorpe wrote: > > > > On Wed, Feb 26, 2025 at 06:49:18PM +0800, Xu Yilun wrote: > > > > > > > > > E.g. I don't think VFIO driver would expect its MMIO access suddenly > > > > > failed without knowing what happened. > > > > > > > > What do people expect to happen here anyhow? Do you still intend to > > > > mmap any of the MMIO into the hypervisor? No, right? It is all locked > > > > down? > > > > > > This patchset expects it to be mmap'able as this is how MMIO gets mapped in > > > the NPT and SEV-SNP still works with that (and updates the RMPs on top), the > > > host os is not expected to access these though. TDX will handle this somehow > > > different. Thanks, > > > > I'm expecting you'll wrap that in a FD, > > A KVM memslot from VFIO's fd similar to gmemfd's fd, and skip VMA? Doable > but 1) creates a KVM->VFIO dependency to do gpa->hpa translation 2) is not > necessary in the AMD case (although host-mmap of guest-assigned private BAR > is way too easy way of shooting yourself in the foot). But since it is necessary in other cases, the code will be there and everyone should just use it.. > > since iommufd will not be accessing MMIO through mmaps. > > here I do not follow, why would iommufd care about MMIO? or it is about p2p > DMA? Thanks, Yes, p2p dma Jason
