Re: [Xen-devel] Sharing display between guests

[Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>]

Hi Ian,

On Mon, Jul 06, 2015 at 12:53:49PM +0100, Ian Campbell wrote:
> (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?

I'd like to have both guests as isolated from each other as possible.

But there's two sub-issues here actually:

1) Being able to have two VMs showing stuff on the same framebuffer at
the same time, without being aware of the other. If we could make pvfb
run on a DRM/KMS plane, that would be perfect for us. Another solution
would be to split the framebuffer in half and have pvfb running on
those two halves.

2) Then, one of the guests would be Android, which really requires
OpenGL, but the second guests would ideally use it as well, but if it
complicates things (and it really seems like it does), we can drop
that from the requirement, which would make us fall in the "exactly
one guest" case you were talking about (except that it wouldn't dom0,
but one of the domU's that would access it).

Our hardware is an A33-based board, that uses a Mali. I'm not exactly
sure about what you meant with your "if the hardware isn't too
strange". Is there features or hints I should be looking for?

> (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.

Ok, so I guess that rules out entirely being able to use the GPUs from
both VMs.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachment: signature.asc
Description: Digital signature

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