2024-12 Update and Notes
This page will be updated during the month and is not final until after the 1st week of January.
Summary of Month
Plans
Finalize plans for AMD demo in January
Make the demos easier for people to run by optionally fetching pre-built binaries and maybe create a container
Add demo for the Xen VM to VM via FFA work
Stretch goal: have first draft of virtio spec w/ virtio-msg in our fork
Highlights
Issues/Changes
Meeting notes December 5
Updates from Armelle?
Eyrton virtio-msg device side in Trusty (using Viresh’s kernel work)
Prebuilt manifest working and documented to Viresh
for those with access the link is https://drive.google.com/corp/drive/folders/1xY-KTE2sJ7FXXAqbNT5qPMLhVUrOdhE2
Working on publishing trusty for Viresh
Testing VM to Trusty
Updates from Edgar?
X86 to ARM now running Xen on both sides but using Dom0 only for now
Looking are running virtio-msg-proxy also as desire to run unmodified kernel, working with KVM having issues with Xen
Xen x86 Dom0 should work ok but having issues with DOMU memory, Doing Foreign map but that does not seem to be enough.
Maybe the IOMMU is not setup?
X86 DOM0 w/ qemu-proxy, DOMU has driver
ARM is having issues accessing
Updates from Viresh?
Meet to figure out how to test
At first will do FFA memory sharing but do it on the fly as with Xen
Vincent is already doing memory sharing with Secure World for his SCMI in secure world work
First memory sharing will be the virtqueues themselves
Then tackle buffers on the FLY
THIS IS NOT THE FINALE SOLUTION
Arnaud: I have something that is doing things
kmalloc with bounce buffer should be supported as a fallback always
The addresses used in virtqueues is mapped via the DMA layer anyway
FFA implementation updates
User space API /dev/virtio-msgN bus tied to underlying parent device
DOM0 start fixup, create device at first message
Branches in howto have been updated but not instructions
Updates from Bertrand?
Updates from Arnaud?
Updated I2C demo kernel side co-processor to kernel
Need buffers in each direction
How to handle errors?
Bertrand: I have error handling at FFA bus level
Started discussion of interrupt context vs not for I2C and GPIO
Updates from others?
Actions:
Need to handle errors better
Add error bit to the msg type byte
Async status report of “Needs Reset” is the proper way to declare a device level error to the driver transport level
Bus crash should report error to each device and then wait for implementation specific recycle
Meeting notes December 19
Need to discuss Interrupt context / vs thread context for I2C & GPIO
Edgar. Bertrand, Dan, Arnaud,
Bertrand:
First draft of message defs has been ported to latex and included in
Need to figure out how to introduce enough “bus” concept to write the std bus messages
Error handling
Need an error message: right now use ascii string, maybe use posix errno?
Differentiate temp error vs perm error
Need a bus error message
Hot Plug & Unplug
Hot plug should be easy
Unplug of a device will look similar to error
Bus level error, seems harder?
Edgar: x86 dynamically allocates memory for queue, Use small memory area for anchor block data structures
Bus msg: New device
Bus msg: bus health => keepalive watch dog
Device goes away
How does standard virtio handle driver shutdown when buffers are outstanding in the device
Unregister device will probably send messages to the device, who’s job is it to drop/null out these messages: bus implementation? transport implementation?
Should send API from transport → bus have a error return code? This allows use to indicate error on EVENT_AVAIL (which does not have rx msg)
Edgar
resolved memory issue: x86 on DOM0 is not 1:1 mapped so added kernel API to get address from its POV
guest still hangs and need to debug that
kernel case: just works
Arnaud:
have implemented the queue structure he and Bill defined
Zephyr side is working also