Hi Trilok,
On Thu, 9 Jun 2022 at 19:15, Trilok Soni quic_tsoni@quicinc.com wrote:
Hello Vincent,
On 6/2/2022 12:11 AM, Vincent Guittot wrote:
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 backendYes, 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
We have now posted Linux kernel based scmi backend on the mailing list, so you may want to provide comments there and we can weigh in the options?
Yes, I have seen the patchset on the mailing list but haven't reviewed it yet. It is on my todo list
From previous discussion with Satyaki, Azzedine and Srinivas, one goal of the patchset is to leverage on the linux clock drivers that are already implemented in the kernel
https://lkml.org/lkml/2022/6/9/153
---Trilok Soni