On Wed, Apr 29, 2020 at 2:57 AM Jason Wang <jasowang@xxxxxxxxxx> wrote: > > > On 2020/4/29 上午4:47, Lepton Wu wrote: > > This is a way to create virtio based devices from user space. This is the > > background for this patch: > > > > We have some images works fine under qemu, we'd like to also run the same image > > on Google Cloud. Currently Google Cloud doesn't support virtio-vga. I had a > > patch to create a virtio-vga from kernel directly: > > https://www.spinics.net/lists/dri-devel/msg248573.html > > > > Then I got feedback from Gerd that maybe it's better to change that to something > > like uvirtio. Since I really don't have other use cases for now, I just implemented the minimal stuff which work for my use case. > > > Interesting, several questions: > > 1) Are you aware of virtio vhost-user driver done by UM guys? > (arch/um/drivers/virtio_uml.c) The memory part is tricky but overall > both of you have similar target. Thanks for reminding me, I was not aware of it. The use case looks a little different: they are trying create virtio devices for user mode linux and it communicated with "host" side. My driver doesn't depends on any HOST/VMM side stuff. Basically we can use it to create virtio device from guest itself. Or even create virtio device on bare metal. > 2) Patch 1 said it's userspace virtio driver, which I think it is > actually "userspace virtio device" Updated in version 2 of this patch. > 3) Need to be verbose on how the vring processing work in the commit log > of patch 1 Updated. > 4) I'm curious which testing you want to accomplish through this new > transport, I guess you want to test a specific virtio driver? Here is the whole story: we want to test our custom linux image. In the past, we just test our custom linux image with qemu (and virtio vga), and run qemu session on Google Cloud. As you can see, this is nested virtualization and performance hurts. And more, we have another vm inside our custom linux image. So we want to remove the qemu layer, just run our custom linux image on Google Cloud directly. Then we need some kind of VGA. So a "dummy" virtio vga looks a good fit. > 5) You mentioned that you may want to develop communication between > kernel and userspace, any more details on that? Currently, we don't have such use case. But maybe others can furthermore to extend uvirtio for this. For example, user space can use read/write to actually exchange data with kernel. Then that could be used for simulate more complex use case. > > Thanks > > > > > > Lepton Wu (1): > > virtio: Add uvirtio driver > > > > drivers/virtio/Kconfig | 8 + > > drivers/virtio/Makefile | 1 + > > drivers/virtio/uvirtio.c | 405 ++++++++++++++++++++++++++++++++++ > > include/linux/uvirtio.h | 8 + > > include/uapi/linux/uvirtio.h | 69 ++++++ > > samples/uvirtio/Makefile | 9 + > > samples/uvirtio/uvirtio-vga.c | 63 ++++++ > > 7 files changed, 563 insertions(+) > > create mode 100644 drivers/virtio/uvirtio.c > > create mode 100644 include/linux/uvirtio.h > > create mode 100644 include/uapi/linux/uvirtio.h > > create mode 100644 samples/uvirtio/Makefile > > create mode 100644 samples/uvirtio/uvirtio-vga.c > > > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
