From: Hajime Tazaki <thehajime@gmail.com>
To: johannes@sipsolutions.net
Cc: linux-um@lists.infradead.org, liam@infradead.org, ljs@kernel.org,
ricarkol@google.com, johannes.berg@intel.com
Subject: Re: [PATCH v2 10/10] Documentation: um: document nommu UML
Date: Fri, 24 Jul 2026 15:20:02 +0900 [thread overview]
Message-ID: <m1fr189ael.wl-thehajime@gmail.com> (raw)
In-Reply-To: <20260723113633.19c6669dc151.Ibd7a532eef856a1ea39699a263dfa8a9ded9dc20@changeid>
On Thu, 23 Jul 2026 18:35:51 +0900,
Johannes Berg wrote:
> +When emulating a system with an MMU, UML gives every ``mm_struct`` its own
> +host process with its own host address space, and keeps that address space
> +in sync with the kernel's page tables by issuing ``mmap()``/``munmap()``
> +into it.
> +
> +NOMMU has no per-process address spaces: there is a single "physical" address
> +space that the kernel and every userspace process share. UML models this with
> +a **userspace runner** - an ordinary uml-userspace stub host process, started
> +exactly like an MMU userspace process, but with the whole of "physical" memory
> +(the physmem file) mapped into it at the kernel's addresses:
> +
> +- The runner ``exec()``'s the stub just like the MMU case. The only extra step
> + is that, once it is up, the kernel maps the entire physmem file into it in one
> + go, at the same addresses the kernel uses.
> +- Because NOMMU never remaps, that single mapping is all a runner ever needs:
I was actually not sure what you mean here: "NOMMU never remaps".
could you care to elaborate ?
the subsequent parts are clear to me.
> + there is no per-mm host process, no TLB sync and no ``mmap()`` of individual
> + page-table entries into a child. Userspace code and data - placed in memory
> + by the loader - are directly executable and accessible.
> +- The runner processes hold no per-task state: the kernel loads a task's state
> + on every entry, so there's just one process per CPU.
> +
> +Running a task's userspace therefore only means pointing a runner at that
> +task's code and letting it run until the next syscall or signal
> +
> +Building and running
> +====================
> +
> +Configure and build the ARCH=um kernel normally, but deselect CONFIG_MMU.
> +
> +KUnit tests can be run in NOMMU mode with::
> +
> + ./tools/testing/kunit/kunit.py run \
> + --kconfig_add CONFIG_MMU=n --kconfig_add CONFIG_KUNIT_UML_PCI=n
> +
> +Running a normal userspace requires NOMMU-aware binaries. There is no stock
> +x86_64 NOMMU distribution, but a prebuilt Alpine image with musl-libc and
> +busybox built for NOMMU is available and can be turned into a root image::
> +
> + cid=$(docker create ghcr.io/thehajime/alpine:3.20.3-um-nommu)
> + docker export "$cid" > alpine.tar
> + docker rm "$cid"
> + mkdir alpine-root && tar xf alpine.tar -C alpine-root
> + mke2fs -q -F -t ext4 -d alpine-root alpine.ext4 1200M
> +
> +Then boot it::
> +
> + ./linux ubd0=./alpine.ext4 root=/dev/ubda rw mem=1024m init=/sbin/init
For the alpine packages, I'll contact the distribution once this UML
is upstreamed. And update this part with more proper information
rather than my personal repository.
-- Hajime
next prev parent reply other threads:[~2026-07-24 6:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 9:35 [PATCH v2 00/10] simplified UML/NOMMU approach Johannes Berg
2026-07-23 9:35 ` [PATCH v2 01/10] x86/um: nommu: elf loader for fdpic Johannes Berg
2026-07-23 9:35 ` [PATCH v2 02/10] um: decouple MMU specific code from the common part Johannes Berg
2026-07-23 9:35 ` [PATCH v2 03/10] um: nommu: memory handling Johannes Berg
2026-07-23 9:35 ` [PATCH v2 04/10] um: change machine name for uname output Johannes Berg
2026-07-24 6:50 ` Hajime Tazaki
2026-07-24 6:54 ` Johannes Berg
2026-07-24 7:16 ` Hajime Tazaki
2026-07-24 7:18 ` Hajime Tazaki
2026-07-24 7:18 ` Johannes Berg
2026-07-23 9:35 ` [PATCH v2 05/10] x86/um/vdso: nommu: vdso memory update Johannes Berg
2026-07-23 9:35 ` [PATCH v2 06/10] um: further decouple MMU related code Johannes Berg
2026-07-23 9:35 ` [PATCH v2 07/10] um: nommu: add SMP futex operations Johannes Berg
2026-07-23 9:35 ` [PATCH v2 08/10] um: nommu: add userspace runner processes Johannes Berg
2026-07-23 13:59 ` Johannes Berg
2026-07-23 9:35 ` [PATCH v2 09/10] um: allow deselecting CONFIG_MMU Johannes Berg
2026-07-23 9:35 ` [PATCH v2 10/10] Documentation: um: document nommu UML Johannes Berg
2026-07-24 6:20 ` Hajime Tazaki [this message]
2026-07-24 6:49 ` Johannes Berg
2026-07-24 6:53 ` Hajime Tazaki
2026-07-23 11:50 ` [PATCH v2 00/10] simplified UML/NOMMU approach Lorenzo Stoakes (ARM)
2026-07-23 12:22 ` Johannes Berg
2026-07-23 15:11 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1fr189ael.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=liam@infradead.org \
--cc=linux-um@lists.infradead.org \
--cc=ljs@kernel.org \
--cc=ricarkol@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox