On 2020/4/30 上午11:56, lepton wrote:
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.
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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
