Re: Sharing display between guests

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6206 bytes --]

On Mon, Jul 06, 2015 at 03:23:30PM +0100, Ian Campbell wrote:
> On Mon, 2015-07-06 at 16:10 +0200, Maxime Ripard wrote:
> > On Mon, Jul 06, 2015 at 01:41:34PM +0100, Ian Campbell wrote:
> > > On Mon, 2015-07-06 at 14:26 +0200, Maxime Ripard wrote:
> > > > 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.
> > > 
> > > Right, this portion is a bit more tractable in the short term I think.
> > > 
> > > > 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).
> > > 
> > > IOW give the Android full access to the h/w and have it provide a 2d
> > > pvfb to the other guest, yes I think that could be made to work.
> > 
> > Not really. I was thinking having the display controller in dom0,
> > exposing two pvfb, one for Android, one for the other VM, and the GPU
> > only being passed only to the Android VM.
> > 
> > I don't know whether it makes sense...
> 
> I'm too used to thinking of a graphics device as a single monolithic
> whole, rather than as separate/independent display controller and GPU
> etc and am not quite comfortable yet with this idea that they might be
> independent things which you can mix and match ;-).

Note that I'm not saying it would work though. It's just a thought
from someone not-so-experienced with GPUs and virtualization :)

> To me it seems like the hard bit will likely be the guest side s/w and
> whether you can convince it to be happy with a GPU without the display
> controller it normally expects but a PVFB instead. But I think that's
> pretty much smack bang in the middle of your bailiwick...

That's what I thought, and the reason of me starting this whole
discussion..

Maxime

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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