Hi all,
Looking into the details of the newly created STR-15, I realized it is very similar to STR-14. I think that STR-14 and STR-15 have to be designed together from the start. It might be detrimental to implement one without the other. Below the details.
Historically we started with the Xen LBI (LBI-24), from it we derived STR-9 for the generic virtio work, such as new virtio protocols.
There is a security/safety issue with virtio which has been overlooked so far and it becomes important when introducing virtio to Xen and other type1s. As we discussed a few times during the calls, it is about the virtio backends having to be privileged (having to be in Dom0.) In a typical Xen deployment today, using Xen PV drivers, that is not the case.
To address this concern we created STR-14. (Please ignore the non-virtio deliverables of STR-14 for now.) We decided to go with STR-14, a new card, instead of adding it to STR-9. One of the reasons is that the work is expected to be done using Xen as reference for STR-14 while STR-9 is generic.
The main points covered by STR-14 are:
- Virtio spec changes for unprivileged backends - changes required for pre-shared memory setups - enable dynamical sharing of memory between frontends and backends - pre-shared memory implementation in Linux, Xen, QEMU - dynamically shared memory implementation in Linux, Xen, QEMU
In this context: a) Xen: implementation of the static and dynamic memory sharing b) Linux: virtio frontend, e.g. drivers/net/virtio_net.c c) QEMU (or other virtio backend, I'll use QEMU as example): virtio backend, e.g. hw/net/virtio-net.c
Both STR-14 and STR-15 are about explicitly sharing memory between VMs using virtio. STR-15 seems to correspond to the "using pre-shared memory and memcpys" deliverable of STR-14.
If STR-15 is going to need a new virtio interface, it is likely that the virtio committee will ask us to come up with a single technical solution that works for both STR-14 and STR-15. We need a close collaboration between the two efforts and design it together. In fact, I wonder if it makes sense to just do the work under STR-14.
It is worth noting that the development of STR-14 and STR-15 won't be hypervisor neutral. The Linux virtio frontend changes (b) and QEMU virtio backend changes (c) should be mostly reusable. But there is also a Xen specific component (a). A prototype based on KVM won't work on Xen out of the box.
From a reference implementation perspective, STR-14 has Xen as reference
also because the companies that requested it (ARM, Qualcomm, Xilinx) were interested in Xen and other type-1s. I wonder if it is possible to keep Xen as reference implementation for this work, or raise its priority.
Happy to discuss more. I am also happy to join a call on the topic.
Cheers,
Stefano