Partitioned Container DEMOS repository

run the building script to build and push all the images on the dessertlab docker hub.

The organization is the following: each folder is an application. Within the folder a file called "info" specifies base-name and tag of the image. For each architecture supported there is a subfolder with the name of the architecture (e.g., arm64, amd64).

Standard architectures names like arm64 and amd64 are built following the normal process for building images in the building scripts (build_images.sh or build_single_image.sh). For those, the scripts expect a Dockerfile and related files to create the container image.

When the architecture is "arm64jh", its folder is expected to contain a subfolder for each hardware platform (e.g., qemu, ultrascale). Inside each of those folders, there are the files to create ZIC images, including a Dockerfile and related binaries and configuration files. When creating container images for arm64jh, the building scripts append the name of the hardware platform (for example, qemu or ultrascale, with names taken from the folder name) to the base-name of the image contained in "info" file.

ZIC conventions

As per the first released demo of containerd and runPHI, some conventions are assumed when building a ZIC image.

• The Dockerfile must copy a file called "config.json" into the /boot folder of the container image.
• config.json contains the information required by runPHI, which are the output of the building process of the application.
• To guarantee transparent orchestration, the zic image must contain _zic at the end (e.g., rt-app_zic). This substring is recognized by the patched containerd to automatically append the name of the hardware platform (contained in /etc/containerd/board).

In the following, a list of current fields possible in the config.json:

• os_var: String (defaulted to "") // For future scopes to distinguish runtimes, at the moment only needed to distinguish Linux from libOSes compiled together with the app.
• inmate: String (defaulted to "") // The inmate variable represents the file to be loaded in the ZIC containing the bare metal code or the app with the libOS
• starting_vaddress: String (defaulted to "") // The starting_vaddress variable specifies the virtual address that the binary in inmate is expecting to start. This determines how to remap the memory in the MMU when available. If unsure, leave empty.
• net: String (defaulted to "") // If the ZIC requires the ethernet network shared with management VM
• rpu_req: bool (defaulted to false) // If the ZIC requires to run on an RPU

There are some other fields, which are currently unstable, to optionally support ZICs running on Linux kernels

• cpio: String, (defaulted to "")
• kernel: String (defaulted to "")
• ramdisk: String (defaulted to "")
• dtb: String (defaulted to "")
• initrd: String (defaulted to "")

Example: zephyr-based ZIC images for qemu hardware platform targeting jailhouse hypervisor

Creating and puhing a zic image that is in rt-app/arm64jh/ultrascale, with rt-app/info containing "rt-app_zic 1.0", causes the scripts to create and push an image named rt-app_zicultrascale:1.0 with architecture arm64.

NOTE: Follow this to build a Zephyr binary for a specific application and obtain the zephyr.bin file needed for the image.

1. Create a test image directory named arm64jh to flag that inside there are ZICs

# cd /PATH_TO/partitioned_container_demos
# mkdir -p zephyr_helloworld_test_image/arm64jh

2. Create a folder for each available hardare plaform

# mkdir -p zephyr_helloworld_test_image/arm64jh/ultrascale
# mkdir -p zephyr_helloworld_test_image/arm64jh/qemu

3. Create config.json, info, and Dockerfile files needed to build within the appropriate folders and push the image

config.json

{
  "starting_vaddress": "0x70000000",
  "os_var": "zephyr",
  "inmate": "/boot/hello.bin",
  "net": "yes"
}

Dockerfile

# Use Alpine Linux as the base image
FROM scratch

# Copy the binary into the /boot directory inside the container
COPY zephyr.bin /boot/hello.bin
COPY config.json /boot/
# Optionally, you may want to perform additional actions or configurations here

# Set any required environment variables or expose any necessary ports

# Cleanup unnecessary packages and files to minimize the image size
LABEL org.opencontainers.image.os.features="jailhouse"
# Set the working directory
WORKDIR /boot

# Command to run when the container starts
CMD ["sh"]

info

zephyr-helloworld-test-image 1.0

4. Copy zephyr binary into test image folder

# cp $HOME/zephyr_workspace/zephyrproject/zephyr/build/zephyr/zephyr.bin /PATH_TO/partitioned_container_demos/demos/zephyr_helloworld_test_image/arm64jh

5. Build and push the image

# cd /PATH_TO/partitioned_container_demos
# ./build_single_image.sh zephyr_helloworld_test_image/