Attendees

• Alex Bennée
• Mike
• Ruchika
• Alex Elder
• Mathieu
• Mark
• Wei Chen
• Arnd 
• Viresh
• Matt (Arm)
• BillM
• BillF
• Tom
• Jean Phillip
• Ed Doxat (Arm)
• Steffano (Xilinx)
• Paul Ellis
• Don
• Viresh
• Bogdan Vlad (NXP)
• Trilok Soni  (QuicInc)
• Souvik Chakravarty (ARM)
• Jochim Bech
• Srinvas Ramana (QCom)
• Sumit Semwal
• Loic Pallardy (ST)
• Trilok (QC)
• Srivatsa
• Pratik Patel (QC)
• Francios
• Azzedine (QC)
• Illias
• Sumit 
• Randy

Goals

• Get a view of the engineering support available to work on Stratos.

Discussion items

• Review Action items

OPTEE/Xen/Virtio Ruchikia

• Above presentation
• Stefano: consider adding the Xen/OPTEE tests to Xen GitLAb CI so we can move OPTEE support from experimental
• Pratik: asked about adding FFA support to Xen? Steffano: should be easy
• Discussion about various use cases of secure world vs non-secure

Greybus/i2c discussion Viresh

• i2, SPI can be remote controlled - UNIPRO initially, can be USB virtio

• Google PJ Ara started it, not many users
• Bill - multiple contexts in the communication - maps to rpmsg, Loic had talked about discovery overlapping with rpmsg but the name service has no context. greybus may augment rpmsg, name service announces grey bus master endpoint and you then get information from there. Greybus is an rpmsg payload, which would be a virtoi payload.
• Loic - need to avoid stacking for a simple use case (worried about large pile of code). Should we use greybus and not rpmsg, or a channel for each ? Customers will find it hard to select.
• Bill rpmsg is src and dest port, will need that for whatever greybus is run on. 
• Arnd not sold, it is also easy to do over virtio, Loic limited buy shared memory, rpmsg solves that over the same link, greybus does the same, for virtio we need memory for i2s,spi, gpio
• Alex does this allow access to limited hw: Bill no
• BIll perhaps only one device on i2c is owned by the guest, back ends might be on cortexR or on the host, don't want a virtio que for  every case multiplied by guests
• Arnd wouldn't it be better to have ... 
• MP : we have two cases, communication between host and coprocessor and guests on a host, we should focus on the latter  Bill, we don't want to reinvent for cortex-R, need to be sure about Arch
• Alex : PCI vs Greybus - what's the difference?  BIll, PCI you only have a vidpid, so you need pid for every device, we want abstract class and multiplex over a single virtio bus.
• AE : Greybus means different things to people. aspects  discovery, greybus has a way to have well known port. Second, there is a well-defined way to encapsulate gpio, spi etc into packets, thirdly an implementation that responds to requests, forth multiplexing of greybus
• BM : I owe you some pictures, currently  GB is just encoding existing kernel transitions,  supplier of the manifest is the backend. backend talks to greybus and turns them around to physical interface
• AE this is different to greybus, BillM the firewalling is beyond greybus
• BM virtque is basic transport, GB has master channel and device channels, each channel could be virtque or add a header.  rpmsg is already a multiplexer.
• AB; can have 255 devices, for enumeration greybus is useful
• AB how does enumeration work, do we add strings to a DB, AE. Ara had central DB at Google
• BillM : do you have class identifier, AE the manifest has this
• Jean-Philippe Brucker Just FYI there is a virtio-i2c proposal close to hit the spec https://markmail.org/thread/4s76amlizw77oig7

Action items