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

• HVAC demos can now be run w/o building everything. Anything not already built will be fetched from a git-lfs repo.

• Replication of the Xen VM to VM via FFA demo made progress but needs more debug

• First draft of virtio-msg spec is in our repo. Needs review and additions from Dublin discussion

• AMD continues to make progress on their X86 + Arm demo (aka VPR), both qemu-proxy mode and direct Linux to QEMU

• Linaro (Bill) now has AMD VPR platform to start replicating AMD demo work

• AMD virtio-msg demo target is now Embedded World in March

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

  • https://github.com/Linaro/virtio-msg-spec

  • 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