This page will be updated during the month and is not final until after the 1st week of March.
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?