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, creating a container,

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