Hi Christoph,
On 14.08.20 10:58, Christoph Gerum wrote:
Hello,
Over the last few months, our team has been working on an automatic
configuration utility for jailhouse. As our effort now nears a usable
state, we would like to present it to the jailhouse community.
Our tooling is available on https://github.com/ekut-es/autojail
The documentation is available on
https://atreus.informatik.uni-tuebingen.de/~gerum/autojail/
The tooling works by extracting information about the target hardware
from the Linux runtime system (currently mainly
/sys/firmware/devicetree/),
As you are processing a device tree already, can you also consume an
offline dtb?
Did you also already have a look at system-dt
(https://elinux.org/Device_tree_future#System_Device_Tree_2019.2C_2020)?
That could become the next logical step for dt-based systems.
and then generating jailhouse cell configs
for root- and guest cells from a minimal configuration file.
Important "detail": It comes with a new human-processable configuration
format, you YAML schema, right? Is that format as powerful (or
low-level) as the binary format, i.e. a full replacement of the current
C files? Or does it provide abstractions like "give me 1GB, I don't care
where", or "give me device B, with whatever I/O resources it comes"?
How is the (planned) workflow then? Currently on x86, you call "config
create" and then perform manual tuning on the resulting C config for the
root cell to make it work. I suspect that is what "autojail extract" is
about. In your case, tuning would be done on to the yml file? How would
will the workflow be for non-root cell configs?
Hint: Add a user story to your documents would help getting a big
picture quicker.
It differs from the current jailhouse config in the following ways:
I suspect you meant the current config generator.
- It targets aarch64 instead of x86_64.
A final architecture will have to address all archs, even if the input
for x86 will remain different.
- It supports configuration of guest and root cells.
- It allows a simplified configuration of IVSHMEM_NET.
The current release has the following limitations, which we would like
to address in the coming weeks:
- No generation of configuration for the inmates (networking,
device-tree)
- Dead Simple Memory allocator that will probably give up at a
relatively low memory pressure.
Where does the memory allocator come into play?
- Configuration of inter-cell communication is supported for
IVSHMEM_NET devices only
- Only tested on Raspberry PI 4B
- No configuration of SMMU or other IOMMUs
The current release has so far only been tested on Raspberry PI 4B, and
this announcement mainly is here as a request for comments, and to
evaluate how our work might fit into the general jailhouse ecosystem.
- Would there be interest to somehow integrate it more closely into
the jailhouse ecosystem?
- We would be very interested, if we could use it as a configuration
generator for the current work on memory coloring in jailhouse.
Specifically coloring is a scenario where more tooling support for
config generation and validation is needed, indeed. You may have seen
that new "jailhouse config check" command which performs the latter (and
should work with your approach as well as it processes binary configs),
but we also need more of the former.
So, yes, there is definitely interest in new ideas and concrete
solutions, specifically for arm64 (though not only). After having to
refactor configs/ recently, more than once, I would appreciate a lot if
we could reduce the manual maintenance.
What needs careful thoughts are the possible use cases and workflows. We
need a solution that automates what can be safely automated, ideally
warns when user input or validation is needed and does not stand in the
way when manual tweaking must be applied. That is due to the low
abstraction level of the binary config format the hypervisor consumes.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/a588e2a5-b7cd-7df8-7341-2e7f9da79b6f%40siemens.com.
