On Wed, Apr 09, 2025 at 07:28:47PM +0300, Mike Rapoport wrote: > On Mon, Apr 07, 2025 at 11:16:26AM -0300, Jason Gunthorpe wrote: > > On Sun, Apr 06, 2025 at 07:11:14PM +0300, Mike Rapoport wrote: > > > > KHO needs to provide a way to give back an allocated struct page/folio > > that can be freed back to the buddy alloactor, of the proper > > order. Whatever you call that function it belongs to KHO as it is > > KHO's primary responsibility to manage the buddy allocator and the > > struct pages. > > If order is only important for freeing memory back to page allocator, you > don't really need it. Freeing contiguous power-of-two number of pages with > proper alignment will give the same result, just a tad slower.
What I'm asking for is transparency for the driver. iommu going to be doing: folio = __folio_alloc_node(order >= 0) [.. init struct ioptdesc that is overlayed with struct folio ] folio_put(folio); As that is how you make memdescs work today. So when we add KHO, I want to see: folio = __folio_alloc_node(order >= 0); [.. init struct ioptdesc that is overlayed with struct folio ] kho_preserve_folio(folio); // kexec folio = kho_restore_folio(phys); [.. init struct ioptdesc that is overlayed with struct folio ] folio_put(folio); Working fully. I do not want to mess with the existing folio_put() code just because KHO can't preserve __folio_alloc_node(). Tomorrow someday I think we will switch to a flow more like memory = memdesc_alloc(&ioptdesc, order >= 0); [.. init struct ioptdesc that is a new allocation] kho_preserve_memdesc(ioptdesc) // kexec memory = kho_restore_memdesc(phys, &ioptdesc) [.. init struct ioptdesc that is a new allocation] memdesc_free(memory, ioptdesc); Jason
