From: Johannes Berg <johannes@sipsolutions.net>
To: Hajime Tazaki <thehajime@gmail.com>, hch@infradead.org
Cc: linux-um@lists.infradead.org, ricarkol@google.com,
Liam.Howlett@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v13 00/13] nommu UML
Date: Tue, 11 Nov 2025 09:01:25 +0100 [thread overview]
Message-ID: <0a84c16f862026c82271c0adbc91d98b812a78b4.camel@sipsolutions.net> (raw)
In-Reply-To: <m2framxerm.wl-thehajime@gmail.com>
On Mon, 2025-11-10 at 21:18 +0900, Hajime Tazaki wrote:
>
> What is it for ?
> ================
>
> - Alleviate syscall hook overhead implemented with ptrace(2)
> - To exercises nommu code over UML (and over KUnit)
> - Less dependency to host facilities
FWIW, in some way, this order of priorities is exactly why this hasn't
been going anywhere, and every time I looked at it I got somewhat
annoyed by what seems to me like choices made to support especially the
first bullet.
I suspect that the first and third bullet are not even really true any
more, since you moved to seccomp (per our request), yet I think design
choices influenced by them persist.
People are definitely interested in the second bullet, mostly for kunit,
and I'd be willing to support them in that to some extent.
However, I'm not yet convinced that all of the complexities presented in
this patchset (such as completely separate seccomp implementation) are
actually necessary in support of _just_ the second bullet. These seem to
me like design choices necessary to support the _first_ bullet [1].
[1] and then I suppose the third, which I'm reading as "doesn't need
seccomp or ptrace", but I'm not really quite sure what you meant
I've thought about what would happen if we stuck to creating a (single)
separate process on the host to execute userspace, and just used
CLONE_VM for it. That way, it's still no-MMU with full memory access,
but there's some implicit isolation between the kernel and userspace
processes which will likely remove complexities around FP/SSE/AVX
handling, may completely remove the need for a separate seccomp
implementation, etc.
It would, on the other hand, make it completely non-viable to achieve
the first and third bullets, so given your pursuit of those, one some
level I understand the design right now. I'm yet to be convinced,
however, that those are even worthy goals for (upstream) UML, what use
case would that enable that we really need? Especially considering that
over a longer perspective, NOMMU architectures _are_ on their way out,
and UML will certainly follow once that happens, it won't be the last
remaining NOMMU architecture.
So the only value I see in this is for testing over the net couple of
years, which really doesn't need any sort of significant optimisation or
less reliance on host facilities.
Where do you see this differently?
johannes
next prev parent reply other threads:[~2025-11-11 8:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 8:05 [PATCH v13 00/13] nommu UML Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 01/13] x86/um: nommu: elf loader for fdpic Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 02/13] um: decouple MMU specific code from the common part Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 03/13] um: nommu: memory handling Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 04/13] x86/um: nommu: syscall handling Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 05/13] um: nommu: seccomp syscalls hook Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 06/13] x86/um: nommu: process/thread handling Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 07/13] um: nommu: configure fs register on host syscall invocation Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 08/13] x86/um/vdso: nommu: vdso memory update Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 09/13] x86/um: nommu: signal handling Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 10/13] um: change machine name for uname output Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 11/13] um: nommu: disable SMP on nommu UML Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 12/13] um: nommu: add documentation of " Hajime Tazaki
2025-11-08 8:05 ` [PATCH v13 13/13] um: nommu: plug nommu code into build system Hajime Tazaki
2025-11-10 9:14 ` [PATCH v13 00/13] nommu UML Christoph Hellwig
2025-11-10 12:18 ` Hajime Tazaki
2025-11-11 8:01 ` Johannes Berg [this message]
2025-11-12 8:52 ` Hajime Tazaki
2025-11-12 16:36 ` Tiwei Bie
2025-11-14 6:47 ` Hajime Tazaki
2025-11-25 9:58 ` Johannes Berg
2025-11-28 12:57 ` Hajime Tazaki
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=0a84c16f862026c82271c0adbc91d98b812a78b4.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Liam.Howlett@oracle.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=ricarkol@google.com \
--cc=thehajime@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).