TODO: create initial TODO for proddevel discussions

[firscity]

No description provided.

[lorc]

Well, you forgot list of actually requirements. Something like this:

• Support all possible platform and guest configurations (e.g. Android on H3ULCB or Linux DomU on S4 or no DomU at all)
• Support for virtio configurations
• Allow to setup boot devices for DomD/DomU based on bootloader configuration
• Automatic restart for DomUs
• Backend/fronted configuration for domains
• Ability to stop/start/restart domains from console
• ???
• PROFIT

[firscity]

@lorc, thank you for a comment. I thought this part (at least initial version) will be described by @klogg (as he said in #general), I just summarized some of the potential challenges related to implementation.
I will wait for his response and then merge your comment with @klogg requirements in TODO.

[GrygiriiS]

my 5c. i could be wrongly understood things, so sorry and just ignore below.

As I understood the main goal is to pass safety certification. Now why Zephyr is passing it? Its simple and mostly 100% static - no memory allocations, minimal FS support, no console, high code coverage by tests .. Single multi-threaded binary. So if goal is to pass certification the all dynamic things has to be minimized. In general, Zephyr Dom0 (somebody loading it - i assume u-boot) should just take cfg from place A, binaries for domX form place B (A may be eq B) and just read/apply cfg (which should be well defined), load bins and start them.

What can be place A (cfg):

• obvious choice RAM. bootloader loads cfg blob at PA_A
• xSPI (qSPI) in Memory mapped mode. Direct access from Zephyr (not an expert) with possibility to apply memory restrictions through secure firewalls or MMU.

What is place B (bin):

• same as A
• smth else as binaries could be pretty big

No need to rebuild zephyr every time if cfg data and binaries are well prepared and separated from Zephyr.
All cfg data and binaries manipulations have to be done by external tools.

[GrygiriiS]

After studding what we have Xen + Zephyr Dom0 area, I come up with following ideas related to this "Simple/thin" Dom0 application.

Configuration:

• It seems perfectly ok to have Domians configuration to be specified as static C structures (as it is now) and filled manually. And there is no benefits of adding addition translation layer to build them from Device tree. Lets call it Option1

• The reasonable option2, in my opinion, is to have pretty simple tool to generate Domain config ( as static C structures ) form standard Xen xl.cfg which also could have additional parameters we need ("xt_xl2cfg xl1.cfg xl2.cfg -> dom_cfgs.c"). This external domain cfgs can be optionally added to the project at boot time. Benefits: flexibility by separating cfg from project; standard Xen domain configuration format.

• The option 3 is similar to option 2, but instead of '.c' the binary blob is created by cfg tool, which is loaded by bootloader or attached at the end of project binary. This even more flexible as no rebuild required for Zephyr project.

Loading 'static' binaries:

How DomD/U binaries attached and processed now is definitely no convenient, so the proposal is to use Firmware Image Package (FIP) [1] from TF-A with standard or lightly modifying TF-A tools.

• DomD/U images packed in FIP image.
• FIP image attached to the end of Zephyr application which is known place/addr.
• Zephyr application maps and processes FIP image to get binaries.

Benefits:

• simple;
• No need to rebuild application itself;
• number of configuration can be easily generated/prepared for testing purposes;
• domains cfgs can also be placed in FIP image

Of course, there are will be more technical details to solve, like probably adding custom header in front of FIP image.
[1] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/design/firmware-design.rst#firmware-image-package-fip

[xakep-amatop]

maybe we can reuse LLEXT somehow for loading binaries