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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.