Re: [PATCH 0/1] Add uvirtio for testing

[Jason Wang <jasowang@redhat.com>]

On 2020/4/30 上午11:56, lepton wrote:
> On Wed, Apr 29, 2020 at 2:57 AM Jason Wang <jasowang@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.


Yes, but as I said. Except for the memory table part, the rest could be 
probably reused?

The only difference to me is that, you develop your own uABI while 
virtio_uml uses vhost-user.


> 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.


Then it's better to mention this in the cover letter.


>> 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.


OK.

Thanks


>> 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@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization