RFC: drm/virtio: Dummy virtio GPU

lepton ytht.net at gmail.com
Tue Feb 25 18:33:11 UTC 2020


On Tue, Feb 25, 2020 at 2:29 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> On Mon, Feb 24, 2020 at 03:01:54PM -0800, Lepton Wu wrote:
> > Hi,
> >
> > I'd like to get comments on this before I polish it. This is a
> > simple way to get something similar with vkms but it heavily reuse
> > the code provided by virtio-gpu. Please feel free to give me any
> > feedbacks or comments.
>
> No.
>
> First, what is wrong with vkms?
The total lines of vkms driver is 1.2k+. I think it doesn't work along
itself to provide things like  mmap on prime fd? (I tried it months
ago). Of course, that could be fixed, but then it will bring more
code.  While my "dummy
virtio" code is only around  100 lines. And more, my "dummy virtio"
device actually doesn't really depends on drm system so it's easier to
back port to old kernel.



>
>
> Second, if you really want something simple with the minimal set of drm
> features possible you can write a rather small but still self-contained
> driver when using all the drm helpers (shmem, simple display pipe) we
> have these days.  Copy cirrus, strip it down: drop modesetting code,
> drop blit-from-shmem-to-vram code, drop pci probing.  Maybe add module
> options for max/default video mode.  Done.
I need features like prime export/import, mmap on prime fd etc. And
I'd like the code could work on different kernel version. So if go
with this ways, the actually add more maintain cost in the long term?
since any
changes at drm frame work could need change to it.
>
> What is the use case btw?
We have images works well under qemu + virtio vga, we'd like to run
these images on public cloud service like Google GCE directly.  So I
got the idea that if some how we can run virtio stack without vmm
support. That
actually would help and also let the same image run on other cloud services.
>
> cheers,
>   Gerd
>


More information about the dri-devel mailing list