[virtio-comment] Re: [virtio-dev] Next VirtIO device for Project Stratos?

["Alex Bennée" <alex.bennee@linaro.org>]

Alyssa Ross <hi@alyssa.is> writes:

> [[PGP Signed Part:Undecided]]
> Hi Alex and everyone else, just catching up on some mail and wanted to
> clarify some things:
>
> Alex Bennée <alex.bennee@linaro.org> writes:
>
>> This email is driven by a brain storming session at a recent sprint
>> where we considered what VirtIO devices we should look at implementing
>> next. I ended up going through all the assigned device IDs hunting for
>> missing spec discussion and existing drivers so I'd welcome feedback
>> from anybody actively using them - especially as my suppositions about
>> device types I'm not familiar with may be way off!
>>
>> [...snip...]
>>
>> GPU device / 16
>> ---------------
>>
>> This is now a fairly mature part of the spec and has implementations is
>> the kernel, QEMU and a vhost-user backend. However as is commensurate
>> with the complexity of GPUs there is ongoing development moving from the
>> VirGL OpenGL encapsulation to a thing called GFXSTREAM which is meant to
>> make some things easier.
>>
>> A potential area of interest here is working out what the differences
>> are in use cases between virtio-gpu and virtio-wayland. virtio-wayland
>> is currently a ChromeOS only invention so hasn't seen any upstreaming or
>> specification work but may make more sense where multiple VMs are
>> drawing only elements of a final display which is composited by a master
>> program. For further reading see Alyssa's write-up:
>>
>>   https://alyssa.is/using-virtio-wl/
>>
>> I'm not sure how widely used the existing vhost-user backend is for
>> virtio-gpu but it could present an opportunity for a more beefy rust-vmm
>> backend implementation?
>
> As I understand it, virtio-wayland is effectively deprecated in favour
> of sending Wayland messages over cross-domain virtio-gpu contexts.  It's
> possible to do this now with an upstream kernel, whereas virtio-wayland
> always required a custom driver in the Chromium kernel.

That's good to know. I guess there is nothing that prevents the final
display of virtual GPUs from multiple guests being mapped onto the
final presentation? The automotive use case seems to treat each
individual VM with a UI as presenting a surface which the final console
manager composites up together depending on safety rules to display to
the user.

> But crosvm is still the only implementation of a virtio-gpu device that
> supports Wayland over cross-domain contexts, so it would be great to see
> a more generic implementation.  Especially because, while crosvm can
> share its virtio-gpu device over vhost-user, it does so in a way that's
> incompatible with the standardised vhost-user-gpu as implemented by
> QEMU.  When I asked the crosvm developers in their Matrix channel what
> it would take to use the standard vhost-user-gpu variant, they said that
> the standard variant was lacking functionality they needed, like mapping
> and unmapping GPU buffers into the guest.

Is this related to ensuring allocated buffers are properly aligned in
the host address space so the HW can use them without needing to copy
them again? I seem to recall this was one of the topics that came up in
one of the AGL VirtIO GPU workshops with the OpenSynergy people:

  https://confluence.automotivelinux.org/pages/viewpage.action?spaceKey=VE&title=Meeting+Agenda#MeetingAgenda-Jan20,2021

zero-copy is a goal everyone seems to want to make the mapping from
virtual to real hardware as efficient as possible. Of course zero-copy
is very much in opposition to more memory isolation between guests and
hosts (e.g. Xen/pKVM). Everyone it seems wants the moon on a stick.

> So if we wanted to push forward with getting making Wayland over
> virttio-gpu less crosvm specific, I suppose the first step would be to
> figure out with the crosvm developers what functionality is missing in
> the vhost-user-gpu protocol.  That would then make it possible to use
> crosvm's device (with the Wayland support) with other VMMs like QEMU.
>
> (CCing my colleage Puck, who has also been working with me on getting
> Wayland over virtio-gpu up and running outside of Chrome OS.)

Thanks. I'm very much an outside observer when it comes to GPUs so
welcome the expert input ;-)

>
> [[End of PGP Signed Part]]


-- 
Alex Bennée

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/