Re: [Xen-devel] Sharing display between guests

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

(switching to my work address) 

On Thu, 2015-07-02 at 13:13 +0200, Maxime Ripard wrote:
> Hi,
> 
> I've started using Xen on an Allwinner A33, which works great as an
> headless device using the latest PSCI patches in U-Boot.
> 
> However, we would like to do something more with it, and we would need
> to have two VMs accessing the display at once, each one drawing in its
> own part of the framebuffer.
> 
> Something that would look like this:
> 
>    Framebuffer
> +---------------+
> |               |
> |    Guest 1    |
> |               |
> +---------------+
> |               |
> |               |
> |               |
> |    Guest 2    |
> |               |
> |               |
> |               |
> +---------------+
> 
> Where thing start to get interesting is that the second guest would be
> running Android, and as such would need OpenGL support, and access to
> the GPU, and that ideally the first guest would need to be able to
> draw over all the screen to create some kind of a drop-down menu.
> 
> Our first thought was to use two different planes of a DRM/KMS driver,
> one for each VM, with the second guest having the primary plane, and
> the first guest having an overlay, and we would set it up in dom0.
> 
> That would mean that we would have a static "composition", that would
> be setup once and we could forget about it during the life of the
> system.
> 
> This way, we would also have a fixed size framebuffer assigned to
> Android, which is much easier to support, and since we have total
> control over the application in the first guest, we would be able to
> control how much "transparency" we want to leave (== how much of
> Android do we want to be displayed), and we would be able to create
> our drop-down menu.
> 
> Now the hard part: is such a setup possible at all with Xen? Can we
> export a single plane to a guest and let it be the only user of it? If
> that is possible, how would that interact with the 3D acceleration?

As it stands today Xen supports exposing a 2D only PV graphics device
(called "pvfb", essentially a flat/linear framebuffer) to guests, I
think this has limited 2D acceleration support let alone 3D support. You
can also (at least in principal, i.e. if the hardware isn't too strange)
pass a GPU through to exactly one guest (often it's just dom0).

Some people have also (I think) managed to use pvfb to expose a real
linear fb to a guest, e.g. a "surface" in the real GPU which is setup by
some more privileged domain.

But, it sounds like you really want a way to expose the GPU
functionality (i.e. 3D support) to at least one if not both guests.

Are you expecting Guest 1 and Guest 2 to be isolated from each other in
a secure way? Or is one considered to be more privileged than the other?

(disclaimer: From here on I'm a bit outside the realms of things I'm
getting even further from the space where I'm confident in my own
understanding...)

Various people have tried to solve this usecase by providing a PV 3D
(OpenGL, Gallium, etc) protocol over the PV FB, but I think this turns
out to be quite tricky (in terms of shuffling textures around as well as
being able to validate the command stream) and generally little comes of
it beyond a PoC. (It's been quite some time since I've seen someone try
this approach).

The other approach would involve exposing the actual hardware to the
guest(s). In general unless your hardware has some special features
(vGPU or SR-IOV or something similar) it is rarely safe to let two
guests access the same bit of h/w unless they are both willing to
co-operate and are assumed to be mutually destructive.

Various folks, including Globalogic who Dario pointed too and Intel with
XenGT (which has been renamed but I don't recall the new name) have
tried to take a hybrid approach emulating parts of the device in some
privileged layer and exposing some parts of the h/w directly to the
guest. AIUI this is necessarily specific to a particular GPU device and
needs the device to have some convenient properties, but falls short of
requiring full "virtualisability" of the h/w ala vGPU or SR-IOV.

> If not, is it something that is conceptually flawed, or does one just
> need to write the appropriate amount of code? Do you have a better
> solution to this problem?

I don't think it is conceptually flawed, but I also think it's not an
easy problem (sorry).

> 
> Thanks a lot for your feedback,
> Maxime
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel