From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D48FEC433E0 for ; Thu, 18 Mar 2021 14:18:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AAF8364E01 for ; Thu, 18 Mar 2021 14:18:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231305AbhCRORh (ORCPT ); Thu, 18 Mar 2021 10:17:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231856AbhCRORd (ORCPT ); Thu, 18 Mar 2021 10:17:33 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D09B2C06174A for ; Thu, 18 Mar 2021 07:17:33 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id j25so3585469pfe.2 for ; Thu, 18 Mar 2021 07:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version; bh=OTNvgazATmy7ZYFAJWGox1akFGRb69EdZteL6XQDbu8=; b=W+0qBirsAp7+6t49z1jp8Vp2U0QfKzlYfUsZmR4ZA1y/o7ASdYuU2plwpBUAuI0DFJ T6cJOrs1f/Mu52+VTmV+gHdtLDB9zMU+tjJbv+vNQcwGYDvoJI4aWZZNJfUnaKNJ1Kuo 1SmRh4Qml0htOzglhe+SlVJLnK1zbtGnOhNaVpAaEb7Cwm6gXJ0hq9Tunvczn7BDhsNc bewPOOzS1kRSRIZIrqyvRqrtdDHeLEWEhSdpv9vYMnU+4DQ2Qlr4ngQhYVXPg+b43MZp QidJQmlFOATLTwGVZo+yV8ag79In1piIxD3Ye2jtSgphZ+akCahrBTkNKPvvcEQghSYQ MTTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version; bh=OTNvgazATmy7ZYFAJWGox1akFGRb69EdZteL6XQDbu8=; b=OVB7TRDbBfllINgAfZc/h7ktYXNlGuRuv9OVbDk+eH/VvCfY1n5O1BxXHGYizg912M emQsmNOLYSqhvjrO0R9mFO7pE6GiJC0l+7dw3KymDwOej/Pvqback54pJcwWZzE7YlWu gqZKOe2GxHAo8nH3uR/IGBSDgqq0YCCrR8AXUQ3uUJPyajyKQC+K+2Io5InRlTcg9uM6 g0J6EiBXVd0qdMy+MbHJSRIW6NejuMHqmVc4YfsnI5mvvhcuZsM4HgpPCBE9Uk1DUslu E32z8ngCh6B3BixHFgL5XgDZ3LfsQaECa4BSovMf+MDAst1FiP+eZ9XViTrD4gvqWq2p 9AbQ== X-Gm-Message-State: AOAM5322Mo6j+UzfQoKgKF0+yZPgqqDhBLyfvVi7u2tbGJDw/Tfyg8lQ znzwgteEg4C6+O6MpY7mUGU= X-Google-Smtp-Source: ABdhPJxs8YcPvg4KsrIQs9N7UZji5D1G+8ksW+uIIJw+mB6rLyzBuDdr7Qo9kz5swGKVa+uXKZBjow== X-Received: by 2002:a65:6a4b:: with SMTP id o11mr7219990pgu.138.1616077053156; Thu, 18 Mar 2021 07:17:33 -0700 (PDT) Received: from sun.local.gmail.com (219x123x138x129.ap219.ftth.ucom.ne.jp. [219.123.138.129]) by smtp.gmail.com with ESMTPSA id s8sm2737546pjg.29.2021.03.18.07.17.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Mar 2021 07:17:32 -0700 (PDT) Date: Thu, 18 Mar 2021 23:17:36 +0900 Message-ID: From: Hajime Tazaki To: johannes@sipsolutions.net Cc: tavi.purdila@gmail.com, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, linux-kernel-library@freelists.org, linux-arch@vger.kernel.org, retrage01@gmail.com Subject: Re: [RFC v8 00/20] Unifying LKL into UML In-Reply-To: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> References: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Hello, On Wed, 17 Mar 2021 23:24:14 +0900, Johannes Berg wrote: > > Hi, > > > One use case where this matters are non OS environments such as > > bootloaders [1], running on bare-bone hardware or kernel drivers [2, > > 3]. IMO it would be nice to keep these properties. > > OK, that makes sense. Still, it seems it could be a compile-time > decision, and doesn't necessarily mean LKL has to be NOMMU, just that it > could support both? > > I'm really trying to see if we can't get UML to be a user of LKL. IMHO > that would be good for the code, and even be good for LKL since then > it's maintained as part of UML as well, not "just" as its own use case. > > > > If your abstraction was instead "switch context" then you could still > > > implement it using pthreads+mutexes, or you could implement it using > > > fibers on windows, or posix contexts - but you'd have a significantly > > > reduced API surface, since you'd only expose __switch_to() or similar, > > > and maybe a new stack allocation etc. > > > > You are right. When I started the implementation for ucontext it was > > obvious that it would be much simpler to have abstractions closer to > > what Linux has (alloc, free and switch threads). But I never got to > > finish that and then things went into a different direction. > > OK, sounds like you came to the same conclusion, more or less. > > > > Additionally, I do wonder how UML does this now, it *does* use setjmp, > > > so are you saying it doesn't properly use the kernel stacks? > > > > > > > To clarify a bit the statement in the paper, the context there was > > that we should push the thread implementation to the > > application/environment we run rather than providing "LKL" threads. > > This was particularly important for running LKL in other OSes kernel > > drivers. But you are right, we can use the switch abstraction and > > implement it with threads and mutexes for those environments where it > > helps. > > Right - like I pointed to USFSTL framework, you could have posix > ucontext, fiber and pthread at least, and obviously other things in > other environments (ThreadX anyone? ;-) ) I also have an idea for a ThreadX in future, which also implements actual context in the application/environment/host side (not in kernel side, as others do). Though this environment may not provide mprotect-like features, there is still a value that the application can run Linux code (e.g., network stack) for instance. # This story is about our old work of network simulation. https://lwn.net/Articles/639333/ > > > But conceptually, why wouldn't it be possible to have a liblinux.so that > > > *does* build with MMU and userspace support, and UML is a wrapper around > > > it? > > > > > > > This is an interesting idea. Conceptually I think it is possible. > > There are lots of details to be figured out before we do this. I think > > that having a NOMMU version could be a good step in the right > > direction, especially since I think a liblinux.so has more NOMMU > > usecases than MMU usecases - but I haven't given too much thought to > > the MMU usecases. > > Yeah, maybe UML would be the primary use case. I have been thinking that > there would be cases where you could combine kunit and having userspace > though, or unit-style testing but not with kunit which is "inside" the > kernel, but instead having the test code more "outside" the test kernel. > That's all kind of handwaving though and not really that crystallized in > my mind. > > That said, I'm not entirely sure NOMMU would be the right path towards > this - if we do want to go this route it'll probably need changes in > both LKL and UML to converge to this point, and at least build it into > the abstractions. > > For example the "idle" abstraction discussed elsewhere (is it part of > the app or part of the kernel?), or the thread discussion above (it is > part of the app but how is it implemented?) etc. I agree that LKL (or the library mode) can conceptually offer both NOMMU/MMU capabilities. I also think that NOMMU library could be the first step and a minimum product as MMU implementation may involve a lot of refactoring which may need more consideration to the current codebase. We tried with MMU mode library, by sharing build system (Kconfig/Makefile) and runtime facilities (thread/irq/memory). But, we could only do share irq handling for this first step. When we implement the MMU mode library in future, we may come up with another abstraction/refactoring into the UML design, which could be a good outcome. But I think it is beyond the minimum given (already) big changes with the current patchset. -- Hajime From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMtSw-005T0l-PU for linux-um@lists.infradead.org; Thu, 18 Mar 2021 14:17:39 +0000 Received: by mail-pg1-x535.google.com with SMTP id m3so1524665pga.1 for ; Thu, 18 Mar 2021 07:17:34 -0700 (PDT) Date: Thu, 18 Mar 2021 23:17:36 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v8 00/20] Unifying LKL into UML In-Reply-To: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> References: <8c6f4ba994831b55ce7893f7e8e71a614474b907.camel@sipsolutions.net> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: johannes@sipsolutions.net Cc: tavi.purdila@gmail.com, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, linux-kernel-library@freelists.org, linux-arch@vger.kernel.org, retrage01@gmail.com Hello, On Wed, 17 Mar 2021 23:24:14 +0900, Johannes Berg wrote: > > Hi, > > > One use case where this matters are non OS environments such as > > bootloaders [1], running on bare-bone hardware or kernel drivers [2, > > 3]. IMO it would be nice to keep these properties. > > OK, that makes sense. Still, it seems it could be a compile-time > decision, and doesn't necessarily mean LKL has to be NOMMU, just that it > could support both? > > I'm really trying to see if we can't get UML to be a user of LKL. IMHO > that would be good for the code, and even be good for LKL since then > it's maintained as part of UML as well, not "just" as its own use case. > > > > If your abstraction was instead "switch context" then you could still > > > implement it using pthreads+mutexes, or you could implement it using > > > fibers on windows, or posix contexts - but you'd have a significantly > > > reduced API surface, since you'd only expose __switch_to() or similar, > > > and maybe a new stack allocation etc. > > > > You are right. When I started the implementation for ucontext it was > > obvious that it would be much simpler to have abstractions closer to > > what Linux has (alloc, free and switch threads). But I never got to > > finish that and then things went into a different direction. > > OK, sounds like you came to the same conclusion, more or less. > > > > Additionally, I do wonder how UML does this now, it *does* use setjmp, > > > so are you saying it doesn't properly use the kernel stacks? > > > > > > > To clarify a bit the statement in the paper, the context there was > > that we should push the thread implementation to the > > application/environment we run rather than providing "LKL" threads. > > This was particularly important for running LKL in other OSes kernel > > drivers. But you are right, we can use the switch abstraction and > > implement it with threads and mutexes for those environments where it > > helps. > > Right - like I pointed to USFSTL framework, you could have posix > ucontext, fiber and pthread at least, and obviously other things in > other environments (ThreadX anyone? ;-) ) I also have an idea for a ThreadX in future, which also implements actual context in the application/environment/host side (not in kernel side, as others do). Though this environment may not provide mprotect-like features, there is still a value that the application can run Linux code (e.g., network stack) for instance. # This story is about our old work of network simulation. https://lwn.net/Articles/639333/ > > > But conceptually, why wouldn't it be possible to have a liblinux.so that > > > *does* build with MMU and userspace support, and UML is a wrapper around > > > it? > > > > > > > This is an interesting idea. Conceptually I think it is possible. > > There are lots of details to be figured out before we do this. I think > > that having a NOMMU version could be a good step in the right > > direction, especially since I think a liblinux.so has more NOMMU > > usecases than MMU usecases - but I haven't given too much thought to > > the MMU usecases. > > Yeah, maybe UML would be the primary use case. I have been thinking that > there would be cases where you could combine kunit and having userspace > though, or unit-style testing but not with kunit which is "inside" the > kernel, but instead having the test code more "outside" the test kernel. > That's all kind of handwaving though and not really that crystallized in > my mind. > > That said, I'm not entirely sure NOMMU would be the right path towards > this - if we do want to go this route it'll probably need changes in > both LKL and UML to converge to this point, and at least build it into > the abstractions. > > For example the "idle" abstraction discussed elsewhere (is it part of > the app or part of the kernel?), or the thread discussion above (it is > part of the app but how is it implemented?) etc. I agree that LKL (or the library mode) can conceptually offer both NOMMU/MMU capabilities. I also think that NOMMU library could be the first step and a minimum product as MMU implementation may involve a lot of refactoring which may need more consideration to the current codebase. We tried with MMU mode library, by sharing build system (Kconfig/Makefile) and runtime facilities (thread/irq/memory). But, we could only do share irq handling for this first step. When we implement the MMU mode library in future, we may come up with another abstraction/refactoring into the UML design, which could be a good outcome. But I think it is beyond the minimum given (already) big changes with the current patchset. -- Hajime _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um