2021-09-30 Project Stratos Sync Meeting notes

Participants

  • @Mike Holmes

  • @Mathieu Poirier

  • @Alex Bennée

  • @Vincent Guittot

  • @Matt Spencer (Arm)

  • @Joakim Bech

  • Olesksander (Epam)

  • @Elsie Wahlig

  • Sirivatsa (Qualcomm)

  • Jean-Phillip

  • Artem Mygalev (Epam)

  • Ed Doxat (Arm)

  • @Arnd Bergmann

  • Christopher Clark

  • Diana (NXP)

  • @Tim Benton

Agenda

Discussion topics

Roadmap

Alex: Stubdomain this cycle? - Xen RustCrate - focus on stable hypercalls only - independent of Xen XL libs - not sure what is needed to find domains, rather not just do hello world.

Christoper - want to avoid rebuilding with each new version of Xen: Are there stable calls to find run state etc ?, CC - not sure, but it should be and can be stabilised. CC there is a specific definition to access unstable, I can help. Alex ok , just needs document clean up.

Alex: leaning towards not trying to do this. CC wish I could help with this, am working with a community that cares about it, however. This will expose corners.

Alex vitio backends put them in dom0 - production backends would move to VMs, this is hard for a first pass. Artem why not go for …

Alex : having backends in their own domain not int dom0, and having single exception level unikernel (SCMI) interacting with HW directly

CC Zen terminology is driver domain, stub domain is encapsulated QEMU emulator, driver domain is host backend and run the physical device driver. AM: we do the same with very thin dom0

Alex: interest in Rust is that it is an alternative to using an RTOS, just have a bare metal loop

AM : rust is an issue for us - we target Xen for safety cases, anything that cant be certified cant be used, Rust is missing this. Rust may be 1-5 years away

CC openXT ? we have used other language

Matt - when RR gave update to this group, it is on the route to be certified, AM is RR working with Dave,

AB virtio backends we did in C and converting to Rust allowed much more confidence in the code, leading us to want to start in Rust

ALEX: WE DECIDED to do this

AB: what interface should we target, does it matter ? GPIO / i2c not very impressive for a demo, would like video-video. Shows common frontend with a backend.

Joakim, I2c does open many use cases, CC have you got storage ? Alex: there are existing implementations. CC block devices to bring the demo up

AB EPAM have done virtio-block, interest in low speed are because you may have multiplexing between guests on a shared bus - perhaps not a good demo.

Joakim: we have been thinking about TPM and these us SPI, VM running that has to access a TPM.

Add a caption


AB Progress updates

  • RPi4 been trying to get this up as a development platform, usual pains. CC I have yocto recipes: Alex is you have PL11 URAT that would be great. CC can do. AM Renasas board - H3 or M3 I can help

  • Fatvirt queue - I am a terrible person no progress since vacation, hope to get to a prototype, still hopeful that this is nicer solution

AB Virtio on Argo CC

CC Written docs on wiki page, design front end is detailed, would be a differentiator for certification cases, does not stop you using different virtio transports.

AB prob not moving fast towards Linux, there is interested in HV agnostic Argo, which enables mandatory access control. AB: will we see users wanting to dynamically select transports. CC embedded I see you could pick agnostic, Argo will allow queries to select higher performance interface. Being aware will bring performance gains

 

Matt SoAFEE

The discussion today is fully aligned with our needs.

 

Action items

Decisions