On Mon, Oct 12, 2020 at 5:17 PM Alex Bennée alex.bennee@linaro.org wrote:
Arnd Bergmann via Stratos-dev stratos-dev@op-lists.linaro.org writes:
Yes, this makes sense. I'll see if I can come up with a basic design for virtio devices based on pre-shared memory in place of the virtqueue, and then we can see if we can prototype the device side in qemu talking to a modified Linux guest. If that works, the next step would be to share the memory with another guest and have that implement the backend instead of qemu.
That seems like a reasonable set of steps. So the pre-shared region will be the source of memory for the virtqueues as well as the "direct" buffers the virtqueues reference?
Yes, my rough idea would be to stay as close as possible to the existing virtio/virtqueue design, but replace the existing descriptors pointing to guest physical memory with TLV headers describing the data in the ring buffer itself. This might not actually be possible, but my hope is that we can get away with making the ring buffer large enough for all data that needs to be in flight at any time, require all data to be processed in order, and use the virtq_desc->next field to point to where the next header starts.
This however limits the total size of a queue to 512KB (16 bytes times 32678 index values) like the current limit of the descriptor array, and that may not be enough for all devices.
Arnd