Re: [PATCH bpf-next 0/5] bpf: Expose pinned arenas as sized bpffs files

[Andrea Righi <arighi@nvidia.com>]

Hi Alexei,

On Fri, Oct 16, 2026 at 07:03:55PM +0000, Alexei Starovoitov wrote:
> On Sun, Oct 11, 2026 at 12:45 AM Andrea Righi <arighi@nvidia.com> wrote:
> > The guest scheduler can create its own arena and allocate pages from
> > that NUMA node. Those guest physical pages are backed by the host arena,
> > so host and guest BPF programs can access the same memory through their
> > respective arenas.
> 
> in addition to what Josh said...
> 
> That node is ordinary RAM for the guest.
> When the guest scheduler exits arena_map_free() does __free_page() and
> the page goes back to the guest's buddy allocator. Nobody tells the host.
> The host prog keeps writing at that offset into whatever the guest
> allocates there next.
> NO_FREE in the guest doesn't help. It covers the kfunc only.

Right, that's a design problem, NO_FREE only protects the host side, the
guest side lifetime is not covered at all, so the host can corrupt guest
memory after the guest scheduler exits.

> 
> Patch 5 needs a 16M node (256M on ppc) to get one page into the guest
> arena. Arena is 4G at most and it's one arena per prog, so that's
> 256 guests per host scheduler.

Agreed, the memory block granularity makes the NUMA node approach
wasteful and doesn't scale.

> 
> The NUMA node is a way to avoid teaching arena to use pages that it
> didn't allocate. I think that's the missing piece in either model:
> host allocates -> guest arena is populated from a BAR,
> guest allocates -> host arena is populated from pinned guest pages.
> As Josh said the BAR is needed for the doorbell anyway.
> 
> If arena can do that, can the host side take the pages from memfd
> with memfd_pin_folios() like udmabuf does ?
> VMM can map memfd at any address and offset already.
> Then no need for NO_FREE, EXPORT, sized file in bpffs, 2nd kind of vma
> in arena, etc.

Agreed, this is much simpler and it covers both models. Mapping the BAR
linearly into the guest arena also gives both sides a fixed rendezvous
point (offset 0 of the memfd is a known address in both arenas), which
removes the out-of-band offset discovery that the selftest does via
/proc/self/pagemap.

I'll drop NO_FREE, EXPORT and the bpffs changes and rework the series
around arena_map_ext_pages() + bpf_arena_import_memfd(), starting from
your patch.

Essentially the plan is:
 1) host: bpf_arena_import_memfd() (based on your patch),
 2) guest: populate the guest arena from a BAR using
    arena_map_ext_pages() (in QEMU, ivshmem-plain with the same memfd
    as memory backend, so no VMM changes),
 3) convert the two-guest selftest to this path.

> 
> The loader does memfd_create() or opens a file in tmpfs, calls
> bpf_arena_import_memfd(&arena, addr, cnt, fd, off) from a syscall prog
> and gives the same file to QEMU the way patch 5 does with the pin.
> The imported pages stay until the arena is freed, so it's NO_FREE for
> the shared part only. libarena keeps working in the rest of the arena.

That's fine for a single long-running guest, but with VMs coming and
going the host arena would only grow (this was also Josh's concern about
the high watermark). Would it be ok with an explicit release of an
imported range (clear the ptes, flush, set rt_own back, unpin the
folios)? A BPF prog touching a released range would then hit the usual
arena fault handling, like any unallocated page.

> arena_map_ext_pages() is what a BAR in the guest or pinned guest pages
> in the pvsched model would call.

For the BAR case the guest needs struct pages for the BAR memory
(memremap_pages() / ZONE_DEVICE or similar) to go through
arena_map_ext_pages(). I'll look into the least invasive way to do that.

> What is missing: user space has to mmap the memfd to see these pages.
> The arena vma gives SIGBUS there.

I think that's acceptable for the hint channel: the userspace side of
the scheduler can mmap the memfd (or the BAR in the guest) separately
and use offsets.

Thanks,
-Andrea