...
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
get agreement with ourselves and the Viresh update his demo (w/ RustVMM based device model)
Nice to have: QEMU aligned with this as well, well defined interface between kernel and device model/vmm (and Xen & kernel
...