/
2025-02 Update and Notes

2025-02 Update and Notes

Owned by Bill Mills
Last updated: about 7 hours ago
3 min read

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

Highlights

  • 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

Meeting Notes Feb 13

  • Only topic of the meeting was spec readiness for the 1st RFC targeted to next week

  • Bertrand’s PR #5 was well reviewed by Arnaud, Bertrand incorporated the input and Alex merged during the meeting.

  • Bill created some issues before and during the meeting, these were discussed during the meeting and Bertrand took the action to address them as he sees fit

  • We discussed RFC format and cover letter

    • RFC from: bill.mills@linaro.org

    • Signed-off-by: Bill @ Linaro, Bertrand @ Arm, Edgar @ AMD, Arnaud @ ST, Someone @ Google ??

    • Cover letter should point to:

      • HVAC intro slides

      • HVAC demo repo or container

      • Viresh’s kernel tree

      • Edgar’s QEMU tree

      • Arnaud’s OpenAMP library code

      • (Point out that the demos and code bases each use different state of the spec and are not aligned to spec RFC)

  • AI: Bertrand update for the issues list

  • AI: Bill to ask for Signed-off-by from: Edgar @ AMD, Armelle if someone from Google can signoff or at least make a statement of interest/commitment to use

  • AI: Arnaud & Dan to try hvac-demos

  • AI: Bill to make running a container easier and to publish a container image

Meeting Notes Feb 27

  • 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 wait until Viresh 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 (/dev/virtio-msgN)

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

 

Related content