[PATCH 0/1] Add uvirtio for testing

lepton
2020-04-30T03:56:09Z

On Wed, Apr 29, 2020 at 2:57 AM Jason Wang <jasowang at redhat.com>
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
> >
>