Re: [RFC PATCH 01/12] dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI

[Christian König]

Sending it as text mail to the mailing lists once more :(

Christian.

Am 15.01.25 um 15:29 schrieb Christian König:
> Am 15.01.25 um 15:14 schrieb Jason Gunthorpe:
> > On Wed, Jan 15, 2025 at 02:46:56PM +0100, Christian König wrote:
> > [SNIP]
> > > > Yeah, but it's private to the exporter. And a very fundamental rule of
> > > > DMA-buf is that the exporter is the one in control of things.
> > I've said a few times now, I don't think we can build the kind of
> > buffer sharing framework we need to solve all the problems with this
> > philosophy. It is also inefficient with the new DMA API.
> >
> > I think it is backwards looking and we need to move forwards with
> > fixing the fundamental API issues which motivated that design.
>
> And that's what I clearly see completely different.
>
> Those rules are not something we cam up with because of some 
> limitation of the DMA-API, but rather from experience working with 
> different device driver and especially their developers.
>
> Applying and enforcing those restrictions is absolutely mandatory must 
> have for extending DMA-buf.
>
> > > > So for example it is illegal for an importer to setup CPU mappings to a
> > > > buffer. That's why we have dma_buf_mmap() which redirects mmap()
> > > > requests from the importer to the exporter.
> > Like this, in a future no-scatter list world I would want to make this
> > safe. The importer will have enough information to know if CPU
> > mappings exist and are safe to use under what conditions.
> >
> > There is no reason the importer should not be able to CPU access
> > memory that is HW permitted to be CPU accessible.
> >
> > If the importer needs CPU access and the exporter cannot provide it
> > then the attachment simply fails.
> >
> > Saying CPU access is banned 100% of the time is not a helpful position
> > when we have use cases that need it.
>
> That approach is an absolutely no-go from my side.
>
> We have fully intentionally implemented the restriction that importers 
> can't CPU access DMA-buf for both kernel and userspace without going 
> through the exporter because of design requirements and a lot of 
> negative experience with exactly this approach.
>
> This is not something which is discuss-able in any way possible.
>
> > > > As far as I can see that is really not an use case which fits DMA-buf in
> > > > any way.
> > I really don't want to make a dmabuf2 - everyone would have to
> > implement it, including all the GPU drivers if they want to work with
> > RDMA. I don't think this makes any sense compared to incrementally
> > evolving dmabuf with more optional capabilities.
>
> The point is that a dmabuf2 would most likely be rejected as well or 
> otherwise run into the same issues we have seen before.
>
> > > > > > That sounds more something for the TEE driver instead of anything DMA-buf
> > > > > > should be dealing with.
> > > > > Has nothing to do with TEE.
> > > > Why?
> > The Linux TEE framework is not used as part of confidential compute.
> >
> > CC already has guest memfd for holding it's private CPU memory.
>
> Where is that coming from and how it is used?
>
> > This is about confidential MMIO memory.
>
> Who is the exporter and who is the importer of the DMA-buf in this use 
> case?
>
> > This is also not just about the KVM side, the VM side also has issues
> > with DMABUF and CC - only co-operating devices can interact with the
> > VM side "encrypted" memory and there needs to be a negotiation as part
> > of all buffer setup what the mutual capability is. :\ swiotlb hides
> > some of this some times, but confidential P2P is currently unsolved.
>
> Yes and it is documented by now how that is supposed to happen with 
> DMA-buf.
>
> As far as I can see there is not much new approach here.
>
> Regards,
> Christian.
>
> > Jason