Re: [Xen-devel] Sharing display between guests

[Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>]

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

> However, there is a wrinkle, which is that passthrough normally requires
> an SMMU, which I'm reasonably sure the A33 doesn't have.

Indeed.

> The usual workaround (which I think Glaballogic use) is to allocate
> guest memory 1:1 (i.e. so it matches in IPA and PA space). This is a
> hack though and we don't like it :-/.

I can imagine :)

> > 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?
> 
> That was mostly a reference to x86 where various combinations of the
> BIOS, Video ROM and the legacy PC architecture can collude to make life
> hard (like not being able to execute the VBIOS twice, or only working in
> primary xor secondary mode, accesses which by-pass the SMMU, etc). I
> don't know specifically of anything similar with ARM or Mali.

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