Re: 5 gigs of contiguos kernel VM shared with userspace

On Sun, 9 Aug 2026 19:54:29 -0700
Adrian Chadd <[email protected]> wrote:

> [snip]
> 
> I .. thought? that technically speaking the kernel virtual address
> space and userland virtual address
> space are (a) not the same, and (b) user VA in the past wasn't even
> guaranteed to be visible by the kernel.
> 
> I know on 64 bit platforms people .. bend the rules / make
> optimisation assumptions like this.
> 
> Are you looking for the /same/ virtual addresses in kernel versus
> userland? Or just some guarantee
> that for a given range of kernel virtual addresses, it's linearly
> mapped in the same linear order to a
> userland process? (ie, knowing the start of the UVA / KVA in their
> respective running modes is enough;
> everything else is just an offset to that.)

Of course, they can not [relied to] be same [like with two mmap-ing userspace
processes in /general/ case], so the talk is about contiguous range in which
addressing can be done by offset. This is a separate question, where UMA will
likely not help me, I just combined in same msg. There are some tools able to
work with offsets, e.g. NetBSD has https://man.netbsd.org/thmap.9 (ported from
userland https://github.com/rmind/thmap/blob/master/src/thmap.c to 
kernel https://nxr.netbsd.org/xref/src/sys/kern/subr_thmap.c), a concurrent
trie-hash map - generic key-value (void *key, size_t len) storage with lock-free
lookups and fine-grained locking inserts/deletes; no hash table resizing needed
(all automatical). But my main question was how to obtain large hunk of kernel
memory - it's first, "how to use" is only meaningful after allocation.

> Because if /that/ is OK, then you can do that with the pager interface
> markj@ is saying and this is how
> a lot of stuff gets exposed between userland/kernel.

Are there examples? The main interface remains copyin(), I thought, which is
exactly I want to avoid.

> If you're looking for other more funkier stuff (eg you're involving
> RDMA, GPU vtable /NIC vtable / system
> IOMMU shenanigans) then maybe explain it a bit more?

No device will ever be involved, I hope (though you reminded me about netmap,
and while it has rigid offsets scheme, probably I can look into how it allows
userspace to mmap() it's memory). I'm exporing using shared memory for
transferring messages with low overhead - from simpler tasks like a tree of
parsed data (we have ARB(3) but that's effectively only one red-black tree)
up to running something complex like to JSC/V8 interpreter with all it's
NaN-boxed ptrs/memory confined to one arena (though if really a language,
I'm not sure absence of pointers to needed kernel objects, like mbufs, while
safe, is not limiting usefullness). Think of it like JSON data model (actually
CBOR, not important for now), just in already parsed form to avoid overheads.

-- 
WBR, @nuclight