Re: [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()

On Mon, Jul 27, 2026 at 01:23:57AM -0300, Jason Gunthorpe wrote:

On Sun, Jul 26, 2026 at 11:17:53AM +0300, Leon Romanovsky wrote:

quoted

Currently, the phys type universally describes memory and can be
reliably translated into any required representation. It is the most
fundamental type we have.

You cannot go from phys to page reliably unless you make assumptions
about the phys, that's the whole issue here. If the callchain expects
and intends to use a page it should really stay in a page and not take
a side trip to phys.

I agree it would help to have some helpers that were more phys based
for the callchains that want that since we are mixing two fairly
different activities in these functions..

Yes, we are agreed here.

But making phys the only output out of the pool isn't going to be an
improvement.

I don't know, phys was natural suggestion due to multiple
page_to_phys/phys_to_page conversions down the road.

BTW how does a struct page even work for decrypted memory? You can't
actually use it that way right? If you try to access it then you'll
get the wrong IPA and it should explode?

Maybe we should be blocking the struct page path entirely for CC
shared?

It will simplify things. Ultimately, this series demonstrates that
CC users must be aware of the memory attribute (CC_SHARED) and struct
page is too generic.

Thanks

Jason