On Thu, Aug 28, 2025 at 12:14 AM Mike Rapoport [off-list ref] wrote:

On Tue, Aug 26, 2025 at 01:20:19PM -0300, Jason Gunthorpe wrote:

quoted

On Thu, Aug 07, 2025 at 01:44:35AM +0000, Pasha Tatashin wrote:

quoted

+   err = fdt_property_placeholder(fdt, "folios", preserved_size,
+                                  (void **)&preserved_folios);
+   if (err) {
+           pr_err("Failed to reserve folios property in FDT: %s\n",
+                  fdt_strerror(err));
+           err = -ENOMEM;
+           goto err_free_fdt;
+   }

Yuk.

This really wants some luo helper

'luo alloc array'
'luo restore array'
'luo free array'

Which would get a linearized list of pages in the vmap to hold the
array and then allocate some structure to record the page list and
return back the u64 of the phys_addr of the top of the structure to
store in whatever.

Getting fdt to allocate the array inside the fds is just not going to
work for anything of size.

I agree that we need a side-car structure for preserving large (potentially
sparse) arrays, but I think it should be a part of KHO rather than LUO.

I agree this can be used by components outside of LUO as well. Ideally
as some helper library so every component can use it. I don't have a
strong opinion on KHO or the stand alone library. I am fine with both.

Chris