On Mon, Jan 20, 2025 at 03:48:04PM -0400, Jason Gunthorpe wrote: > On Mon, Jan 20, 2025 at 07:50:23PM +0100, Simona Vetter wrote: > > On Mon, Jan 20, 2025 at 01:59:01PM -0400, Jason Gunthorpe wrote: > > > On Mon, Jan 20, 2025 at 01:14:12PM +0100, Christian König wrote: > > > What is going wrong with your email? You replied to Simona, but > > > Simona Vetter <simona.vetter@xxxxxxxx> is dropped from the To/CC > > > list??? I added the address back, but seems like a weird thing to > > > happen. > > > > Might also be funny mailing list stuff, depending how you get these. I > > read mails over lore and pretty much ignore cc (unless it's not also on > > any list, since those tend to be security issues) because I get cc'ed on > > way too much stuff for that to be a useful signal. > > Oh I see, you are sending a Mail-followup-to header that excludes your > address, so you don't get any emails at all.. My mutt is dropping you > as well. > > > Yeah I'm not worried about cpu mmap locking semantics. drm/ttm is a pretty > > clear example that you can implement dma-buf mmap with the rules we have, > > except the unmap_mapping_range might need a bit fudging with a separate > > address_space. > > From my perspective the mmap thing is a bit of a side/DRM-only thing > as nothing I'm interested in wants to mmap dmabuf into a VMA. I guess we could just skip mmap on these pfn exporters, but it also means a bit more boilerplate. At least the device mapping / dma_buf_attachment side should be doable with just the pfn and the new dma-api? > However, I think if you have locking rules that can fit into a VMA > fault path and link move_notify to unmap_mapping_range() then you've > got a pretty usuable API. > > > For cpu mmaps I'm more worried about the arch bits in the pte, stuff like > > caching mode or encrypted memory bits and things like that. There's > > vma->vm_pgprot, but it's a mess. But maybe this all is an incentive to > > clean up that mess a bit. > > I'm convinced we need meta-data along with pfns, there is too much > stuff that needs more information than just the address. Cachability, > CC encryption, exporting device, etc. This is a topic to partially > cross when we talk about how to fully remove struct page requirements > from the new DMA API. > > I'm hoping we can get to something where we describe not just how the > pfns should be DMA mapped, but also can describe how they should be > CPU mapped. For instance that this PFN space is always mapped > uncachable, in CPU and in IOMMU. I was pondering whether dma_mmap and friends would be a good place to prototype this and go for a fully generic implementation. But then even those have _wc/_uncached variants. If you go into arch specific stuff, then x86 does have wc/uc/... tracking, but only for memory (set_page_wc and friends iirc). And you can bypass it if you know what you're doing. > We also have current bugs in the iommu/vfio side where we are fudging > CC stuff, like assuming CPU memory is encrypted (not always true) and > that MMIO is non-encrypted (not always true) tbf CC pte flags I just don't grok at all. I've once tried to understand what current exporters and gpu drivers do and just gave up. But that's also a bit why I'm worried here because it's an enigma to me. > > I thought iommuv2 (or whatever linux calls these) has full fault support > > and could support current move semantics. But yeah for iommu without > > fault support we need some kind of pin or a newly formalized revoke model. > > No, this is HW dependent, including PCI device, and I'm aware of no HW > that fully implements this in a way that could be useful to implement > arbitary move semantics for VFIO.. Hm I thought we've had at least prototypes floating around of device fault repair, but I guess that only works with ATS/pasid stuff and not general iommu traffic from devices. Definitely needs some device cooperation since the timeouts of a full fault are almost endless. -Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
