On Wed, 1 Jun 2022 at 22:02, Trilok Soni via Stratos-dev stratos-dev@op-lists.linaro.org wrote:
Hello Alex,
Thank you for the detailed email.
On 5/31/2022 1:07 AM, Alex Bennée via Stratos-dev wrote:
Hi,
This email is driven by a brain storming session at a recent sprint where we considered what VirtIO devices we should look at implementing next. I ended up going through all the assigned device IDs hunting for missing spec discussion and existing drivers so I'd welcome feedback from anybody actively using them - especially as my suppositions about device types I'm not familiar with may be way off!
Work so far
The devices we've tackled so far have been relatively simple ones and more focused on the embedded workloads. Both the i2c and gpio virtio devices allow for a fairly simple backend which can multiplex multiple client VM requests onto a set of real HW presented via the host OS.
We have also done some work on a vhost-user backend for virtio-video and have a working PoC although it is a couple of iterations behind the latest submission to the virtio spec. Continuing work on this is currently paused while Peter works on libcamera related things (although more on that later).
I am not sure what we are using for the rust-vmm backends testing. It will be nice to improve the "vmm-reference" implementation available at the "rust-vmm" project so that we can do the independent testing and it can then also help testing w/ Type-1 hypervisor.
Though vmm-reference can't be used as product it will be a good example for any one to test without bringing in lot of complexity of the QEMU, CrosVM or FireCracker.
Upstream first
We've been pretty clear about the need to do things in an upstream compatible way which means devices should be:
- properly specified in the OASIS spec
- have at least one driver up-streamed (probably in Linux)
- have a working public backend
Yes, all of the above points are really nice and for me having the open-source guest frontend and backend are very important. Industry trend is to have the open-source frontend (in Linux most of the time) but lot of implementations keep proprietary backend eventhough they follow all the aspects of the Virtio specs. It limits the uses of the frontends in my view and it can't help community on testing coverage. "virtio-scmi" comes to my mind for this example.
For the virtio-scmi we are working on adding virtio-scmi support in SCP-firmware which is also used for bare metal power coprocessors and will be available as a Pseudo TA SCMI backend as well. The goal is to use the same SW reference for running on a coprocessor, as a OP-TEE PTA or as a virtio-scmi backend. The upstream is ongoing for the SCP-firmware side and as started in libopenamp and the main open point that needs to be tackled in a proper way, is an efficient transport channel. This will be the next step
for Stratos I think we are pretty happy to implement all new backends in Rust under the auspices of the rust-vmm project and the vhost-device repository.
Yes, agreed.
We obviously also need a reasonable use case for why abstracting a HW type is useful. For example i2c was envisioned as useful on mobile devices where a lot of disparate auxillary HW is often hanging of an i2c bus.
mac80211 wlan / 10 mac80211 hwsim wireless simulation device / 29
I am not sure if this related but virtio-ethernet keeps coming to us as requirement, I am not sure about the what is the support available in the various projects including Xen. This is a non-Mobile requirement particularly from the IOT or Auto segments. It will be nice to do adb over ethernet in the guest VM from the host shell.
memory balloon / 13
This seems like an abandoned attempt at a next generation version of the memory ballooning interface.
virtio-mem is having more features compared to the virtio-balloon spec. We had a offline discussion w/ David H last year on if virtio-mem is suitable for the Type-1 hypervisors or not and in the process we had found various limitations eventhough guest driver code for virtio-mem can be re-used lot w/ modifications to make it work for the Type-1. I will check if Qualcomm can summarize our thoughts on the virtio-mem and why it is only suitable for Type-2 as of now and what changes we may need to do if it can be modified to work on Type-1 hypervisors.
It is very clear that in the embedded usecases virtio-mem/balloon like usecase is needed since you can't predict the size of the memory required for guest VM accurately and sometimes it could be waste of the memory if we do the carveouts or some other options.
It will be nice to add / hotplug the memory for the guest VM in kernel and userspace on-demand.
Another limitation w/ virtio-mem is that we don't have unified / open-source way of determining the pressure in the guest VM and then asking the hotplugging of memory from the host. From what we read Administrator plugs memory from the host VM as needed for the server usecase. It will be nice to have a PSI based implementation on the guest VM which will actively monitor the pressure on the guest VM and asks Host OS to hotplug the memory.
CAN / 36
This is a device of interest to the Automotive industry as it looks to consolidate numerous ECUs into VM based work loads. There was a proposed RFC last year:
https://markmail.org/message/hdxj35fsthypllkt?q=virtio-can+list:org%2Eoasis-...
and it is presumed there are frontend and backend drivers in vendor trees. At the last AGL virtualization expert meeting the Open Synergy guys said they hoped to post new versions of the spec and kernel driver soon:
https://confluence.automotivelinux.org/pages/viewpage.action?spaceKey=VE&...
During our discussion it became clear that while the message bus itself was fairly simple real HW often has a vendor specific control plane to enable specific features. Being able to present this flexibility via the virtio interface without baking in a direct mapping of the HW would be the challenge.
Yes, we are interested to continue the discussion here and see what may be the suitable approach for CAN protocol for Auto like usecases.
Parameter Server / 38
This is a proposal for a key-value parameter store over virtio. The exact use case is unclear but I suspect for Arm at least there is overlap with what is already supported by DT and UEFI variables.
The proposal only seems to have been partially archived on the lists:
https://www.mail-archive.com/virtio-dev@lists.oasis-open.org/msg07201.html
It may be Android related?
I have never heard of it, but I will check the mailing list discussion.
---Trilok Soni
Stratos-dev mailing list -- stratos-dev@op-lists.linaro.org To unsubscribe send an email to stratos-dev-leave@op-lists.linaro.org