Re: [RFC PATCH 0/9] simplified UML/NOMMU approach

Hello,

On Tue, 21 Jul 2026 03:26:50 +0900,
Johannes Berg wrote:

> After Hajime's talk at netdevconf 0x1A I was this time really
> tempted into implementing an approach to NOMMU UML that I'd
> thought about quite a while ago, and here's the resulting
> code. I had prototyped some of this with LLM help, but now
> have pretty much reworked most of it (except boilerplate).
> 
> Instead of using a wholly new architectural interface, new
> process/thread handling, new seccomp machinery etc. this
> just reuses all the existing infrastructure (we're not in
> fact trying to run UML on nommu, but run _as_ nommu), but
> makes runner processes for each CPU instead of each userspace
> MM (as it would be on MMU).
> 
> This eventually results in a far simpler implementation that
> doesn't have all the complexity of the syscall handling yet
> again.
> 
> It's also more capable:
>  - continues working with ptrace
>  - doesn't require disabling SMP
>    (just has a runner per CPU)
>  - should work on 32-bit (untested)
>  - keeps physmem FD, which in theory should allow virtio
>    PCI devices, but PCI doesn't build on !MMU right now

thanks, this is really nice.

I quickly read the patchset and found that [RFC PATCH 8/9] is the core
of your idea, which I agree with your point of simplicity, as well as
the list of compatible features of (the stock version of) UML.

I also understand the need of futex implementation instead of
asm-generic, which only works with !CONFIG_SMP.

I also quickly tested with my local tests (getpid bench, lmbench,
iperf/netperf, and LTP) and all looks fine.  speed measurement is
mostly what I expected.

getpid (nsec)
----------------
  native                  421  
  um			  31983
  um-mmu(seccomp)	  26753
  um-nommu(seccomp)	  3533 
  um-nommu-skas		  27844
  um-nommu-skas(seccomp)  26387
			  

> However, it does go in an entirely different direction
> and while it doesn't entirely close off all things for
> optimisations wrt. syscall speed that the much older
> versions of the NOMMU patchset did, it does create the
> infrastructure in a way that doesn't make that easier.
> 
> Personally, I think the only real use case for this
> whole thing is NOMMU testing (which was requested), and
> we don't really need everything else.
> 
> Note: the futex thing seems odd. I mirrored the existing
> implementation, but I think it's just wrong. There's a
> FIXME in the code for now.
> 
> It does boot ghcr.io/thehajime/alpine:3.20.3-um-nommu
> as was documented before.


What is your plan for this RFC ?

I'm pretty fine with this (skas nommu) mode for nommu UML; it
is certainly useful to detect more bugs if it is available in UML.

I would also like to ask maintainers if my nommu approach can be an
opt-in feature only when specific kernel config is added, probably
marking as '(EXPERIMENTAL)' or `if EXPERT` condition, as there is
potential benefits (speed, less host process use, etc.).

But if you (maintainers) wish and feel this as not an easy option,
I can work for it with later patches as an extension.

btw, maybe I need a better name for (my) nommu code using different
syscall handling, with regard to skas (i.e., separate kernel address
space) mode (e.g., CONFIG_UML_NOMMU_SAS (single address space) etc.).

-- Hajime