Re: [PATCH 0/1] Add uvirtio for testing
On 2020/4/30 上午11:56, lepton wrote: On Wed, Apr 29, 2020 at 2:57 AM Jason Wang 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
Re: [PATCH 0/1] Add uvirtio for testing
On Thu, Apr 30, 2020 at 12:51 AM Gerd Hoffmann wrote: > > On Wed, Apr 29, 2020 at 08:59:18PM -0700, lepton wrote: > > On Wed, Apr 29, 2020 at 4:58 AM Gerd Hoffmann wrote: > > > > > > > 3) Need to be verbose on how the vring processing work in the commit > > > > log of > > > > patch 1 > > > > > > Ecven better a file documenting the interface somewhere in > > > Documentation/ > > I put a uvirtio-vga.c under samples/uvirtio and hope this can serve > > the purpose of the document since currently that's the only tested use > > case. > > Sample code is good, but *commented* sample code would be better. > > > Maybe have a document later if this really get more use cases? > > Well, having good documentation right from the start would help getting > more use cases ;) Now I add document in V3. Thanks. Regards > > take care, > Gerd > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/1] Add uvirtio for testing
On Wed, Apr 29, 2020 at 08:59:18PM -0700, lepton wrote: > On Wed, Apr 29, 2020 at 4:58 AM Gerd Hoffmann wrote: > > > > > 3) Need to be verbose on how the vring processing work in the commit log > > > of > > > patch 1 > > > > Ecven better a file documenting the interface somewhere in > > Documentation/ > I put a uvirtio-vga.c under samples/uvirtio and hope this can serve > the purpose of the document since currently that's the only tested use > case. Sample code is good, but *commented* sample code would be better. > Maybe have a document later if this really get more use cases? Well, having good documentation right from the start would help getting more use cases ;) take care, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/1] Add uvirtio for testing
On Wed, Apr 29, 2020 at 4:58 AM Gerd Hoffmann wrote: > > > 3) Need to be verbose on how the vring processing work in the commit log of > > patch 1 > > Ecven better a file documenting the interface somewhere in > Documentation/ I put a uvirtio-vga.c under samples/uvirtio and hope this can serve the purpose of the document since currently that's the only tested use case. Maybe have a document later if this really get more use cases? Thanks. > > take care, > Gerd > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/1] Add uvirtio for testing
On Wed, Apr 29, 2020 at 2:57 AM Jason Wang 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@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/1] Add uvirtio for testing
> 3) Need to be verbose on how the vring processing work in the commit log of > patch 1 Ecven better a file documenting the interface somewhere in Documentation/ take care, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/1] Add uvirtio for testing
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. 2) Patch 1 said it's userspace virtio driver, which I think it is actually "userspace virtio device" 3) Need to be verbose on how the vring processing work in the commit log of patch 1 4) I'm curious which testing you want to accomplish through this new transport, I guess you want to test a specific virtio driver? 5) You mentioned that you may want to develop communication between kernel and userspace, any more details on that? 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
