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: > > > 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 >
