Summary of Month

Plans

• Finish the 2nd draft virtio spec w/ virtio-msg in our fork and publish it as RFC.

• Move x86 + Arm demo to a new board to show at Embedded World in March

• Several items to make the emulated demo easier for people to run

• Stretch: Rebase the Dual QEMU demo to the latest baseline and contain the shared memory usage to only the single IVISHMEM card

• Stretch: Integrate the ST A7 Linux + M4 Zephyr virtio-i2c demo

...

• First RFC of spec went out on Feb 25

• The demos (hvac-demo) now work on arm64 hosts

• Demo container images are published at docker.io/wmills/hvac-demo (for now)

• Multiple people have tested the demos and all issues have been addressed

...

• Draft RFC went out Friday Feb 21. RFC to virtio-comment west out on Tuesday Feb 25 morning

  • As of today, we have gotten some engagement.

  • Jason Wang (redhat) and Zhu Lingshan (intel) pointed us to a proposal they had in Aug 2022

    • Does virtio transports things over a virtqueue, requires a lower level transport

    • Defines many of the things we do (get/set VQ, get/set Config, get/set status)

    • Seems to be focused on a use case where device side has a “device factory” and driver side asks for devices to be created

    • Uses MSI(-x) exclusively for notification

    • Seems to mix the concept of bus and device

    • Seems to be an alternative to management structure already merged in 1.4 draft

• Bertrand has published a new PR

  • Patch 1: Includes support for version number: makes sense for bus level

    • Common protocol version number makes sense. We should do the same as virtio-mmio and virtio-pci

    • We definitely need a bus level negotiation but that negotiation can set a protocol version that will be

    • There should also be a device level for version number (the bus can answer that message itself if it chooses)

  • Patch 2: Message size change, max message size is in version

    • we need at least 44 bytes

    • GET_DEVICE_INFO

      • size of features

      • size of config

  • Patch 3: Config generation count

    • added in SET_CONFIG GET_CONFIG EVENT_CONFIG

    • remove GET_CONFIG_GEN

  • Patch 4: Mention that bus can do memory sharing and out-of-band notification

  • Other issues not in PR: Error code, and Spec terms

• RFCv2 plan

  • Cover the know issues list (except maybe error code?)

  • First crack at language conformance

  • get agreement with ourselves and the wait until Viresh update has updated his demo to match this (w/ RustVMM based device model)

  • Nice to have : but not blockers for RFCv2

    • QEMU aligned with this as well

    ,

    • FF-A based memory sharing (instead of Xen page grants as is the case today in Viresh’s demo)

    • A well defined interface between kernel and device model/vmm (

    and Xen & kernel

    • /dev/virtio-msgN)

    • Is there anything to define for interface between kernel and Xen?? FF-A should be sufficent right?