Propose an minimal xen-tools

[RFC PATCH 0/2] Propose an minimal xen-tools

Posted by Sookyung Ahn 7 months, 1 week ago

I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.

I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications.
This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
This proposal is based on `dom0less` environment.

The proposed implementation includes:
- Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
- Modifying the build process to selectively include only the necessary components based on the configuration.

This implementation can be effectively applied to the following use cases.
- Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore.
- By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service.
- Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)

I would appreciate any feedback or suggestions you may have regarding this enhancement.
Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.

Sookyung Ahn (2):
changes for minimal-xen-tools
add document minimal_xen_tools.pandoc

--
2.34.1

Re: [RFC PATCH 0/2] Propose an minimal xen-tools

Posted by Anthony PERARD 7 months ago

Hi,

Thanks for the proposal.

On Wed, May 14, 2025 at 07:12:48AM +0000, Sookyung Ahn wrote:
> I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.

FYI, there's a project call `xen-tools`, at
https://github.com/xen-tools/xen-tools/, and having it spell like
reminds me of that external project, and not the tools in this repo.

> I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications. 
> This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
> This proposal is based on `dom0less` environment.
> 
> The proposed implementation includes:
> - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
> - Modifying the build process to selectively include only the necessary components based on the configuration.
> 
> This implementation can be effectively applied to the following use cases. 
> - Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
> - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
> - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)
> 
> I would appreciate any feedback or suggestions you may have regarding this enhancement. 
> Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.

I don't quite like this approach. What is "minimal"? Whatever
definition we can come up with isn't going to fit other's expectation
of a minimal set of tools. Also, the minimum set of tools needed might
be 0, if you only need the hypervisor.

Also, the implementation is quite invasive, with `CONFIG_MINIMAL_TOOLS`
spread through the build system. It also duplicates configurations, with
like "SUBDIRS-y += libs" been written twice in tools/Makefile.

I feel like a better approach would be to have something like:
    ./configure --no-default --enable-flask --enable-hotplug ...

As for the makefiles, instead of having to invent a config option for
every single `SUBDIRS-y` we could have a generic
SUBDIRS-$(subdir-default) where subdir_default is 'y' unless we want to
select a handful of subdirectory.

It might not be necessary to have a config option for everything, you
could deal with some of the stray binary with the tool use to make
package, like RPM where you select which files to packages (as already
suggested), and for other tool just `rm` the few files not needed.

Then, there's `libxenctrl`. For this one, it doesn't feel like a good
idea to make it selectively smaller. Maybe there's a way to extract the
functionality you need into a new lib? We kind of tried in the past to
extract piece of it into lib with a stable interface, like
libdevicemodel, libcall. So it might be a better approach to remove the
need of libxenctrl in your environment.

I hope that help.

Cheers,

-- 
Anthony PERARD

RE: [EXTERNAL] Re: [RFC PATCH 0/2] Propose an minimal xen-tools

Posted by Weber (US), Matthew L 5 months, 1 week ago

Anthony & Ayan,

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of Anthony PERARD
> Sent: Wednesday, May 21, 2025 9:27 AM
> To: Ahn, Sookyung <sookyung.ahn@boeing.com>
> Cc: xen-devel@lists.xenproject.org; Weber (US), Matthew L <matthew.l.weber3@boeing.com>; Whitehead (US), Joshua C <joshua.c.whitehead@boeing.com>; Choi, Anderson <Anderson.Choi@boeing.com>; Wood (US), Brian J > <brian.j.wood2@boeing.com>; Kim, Haesun <haesun.kim@boeing.com>
> Subject: [EXTERNAL] Re: [RFC PATCH 0/2] Propose an minimal xen-tools
>

<snip>
 
> > The proposed implementation includes:
> > - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
> > - Modifying the build process to selectively include only the necessary components based on the configuration.
> > 

@ayan.kumar.halder@amd.com  what is automotive planning to do for XL tool stack in a FuSa configuration?


> > This implementation can be effectively applied to the following use cases. 
> > - Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
> > - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
> > - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain 
> > OS.)
>
> I don't quite like this approach. What is "minimal"? Whatever definition we can come up with isn't going to fit other's expectation of a minimal set of tools. Also, the minimum set of tools needed might be 0, if you only need the hypervisor.
>
> Also, the implementation is quite invasive, with `CONFIG_MINIMAL_TOOLS` spread through the build system. It also duplicates configurations, with like "SUBDIRS-y += libs" been written twice in tools/Makefile.
>

This is good feedback.  The other route we had looked at is establishing a new library that's specifically focused on ARINC653.  The Xen existing ARINC653 scheduling support has some out of tree tools we're looking to integrate in and we're working to finish implementing the standard.  So maybe the basis for this new library is more around ARINC653 and not minimizing the existing XL tool stack.  (We'd have the XL tools disabled in a dom0less safety certification configuration.)

> I feel like a better approach would be to have something like:
>     ./configure --no-default --enable-flask --enable-hotplug ...
>
> As for the makefiles, instead of having to invent a config option for every single `SUBDIRS-y` we could have a generic
> SUBDIRS-$(subdir-default) where subdir_default is 'y' unless we want to select a handful of subdirectory. 
>
> It might not be necessary to have a config option for everything, you could deal with some of the stray binary with the tool use to make package, like RPM where you select which files to packages (as already suggested), and for other tool just `rm` the few files not needed.
>
> Then, there's `libxenctrl`. For this one, it doesn't feel like a good idea to make it selectively smaller. Maybe there's a way to extract the functionality you need into a new lib? We kind of tried in the past to extract piece of it into lib with a stable interface, like libdevicemodel, libcall. So it might be a better approach to remove the need of libxenctrl in your environment.

I see, sounds like the possible way forward is for us to make a libxenarinc static library that pulls in only what's needed.  Then look at the ./configure approach to enabling that library and seeing if we can selectively build solely that new library.

Best Regards,
-
Matthew L. Weber
Associate Technical Fellow / LXF ELISA Aerospace WG Chair

Re: [RFC PATCH 0/2] Propose an minimal xen-tools

Posted by Jan Beulich 7 months, 1 week ago

On 14.05.2025 09:12, Sookyung Ahn wrote:
> I am writing to propose an enhancement to the `xen-tools` for users who require only a minimal subset of its functionality, particularly in safety-critical domains like aerospace.
> 
> I believe that the addition of a new build-time option, `ENABLE_MINIMAL_XEN_TOOLS`, will significantly benefit users by allowing them to build only the essential components needed for their specific applications. 
> This approach not only streamlines the toolset but also reduces the potential for unnecessary complexity in safety-critical environments.
> This proposal is based on `dom0less` environment.
> 
> The proposed implementation includes:
> - Introducing the `ENABLE_MINIMAL_XEN_TOOLS` configuration flag.
> - Modifying the build process to selectively include only the necessary components based on the configuration.
> 
> This implementation can be effectively applied to the following use cases. 
> - Minimal APIs for `dom0less` operation. This involves taking existing Xen functions and shrinking them to minimal needed parts. For example, we can use static device tree instead of XenStore. 
> - By retaining `libxencall` and minimum part of `libxencrtl`, the Hypercall interface can be utilized, enabling support for the Xen ARINC653 Multiple Module Schedules service. 
> - Addition of ARINC653 Part1&2 APIs and services (hosted on the domain OS.)
> 
> I would appreciate any feedback or suggestions you may have regarding this enhancement. 
> Additionally, I would like to emphasize the importance of community input in refining this proposal to ensure it meets the needs of all users.
> 
> Sookyung Ahn (2):
>   changes for minimal-xen-tools
>   add document minimal_xen_tools.pandoc
> 
>  config/Tools.mk.in                    |   1 +
>  docs/designs/minimal_xen_tools.pandoc | 147 ++++++++++++++++++++++++++

Just one nit here: Like you have it in the subject, please prefer dashes over
underscores in the names of new files.

Jan

>  tools/Makefile                        |  19 ++++
>  tools/Rules.mk                        |   9 +-
>  tools/configure.ac                    |  47 +++-----
>  tools/flask/Makefile                  |   4 +
>  tools/hotplug/Linux/Makefile          |   6 ++
>  tools/hotplug/Linux/systemd/Makefile  |   6 ++
>  tools/libs/Makefile                   |   9 ++
>  tools/libs/ctrl/Makefile.common       |  92 +++++++++-------
>  tools/libs/ctrl/xc_private.c          |   6 ++
>  tools/libs/ctrl/xc_private.h          |   7 +-
>  tools/libs/uselibs.mk                 |  76 +++++++------
>  13 files changed, 325 insertions(+), 104 deletions(-)
>  create mode 100644 docs/designs/minimal_xen_tools.pandoc
>