From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: Sharing display between guests Date: Thu, 9 Jul 2015 11:24:59 +0200 Message-ID: <20150709092459.GT28632@lukather> References: <20150702111329.GA19261@lukather> <1436183629.25646.47.camel@citrix.com> <20150706122602.GK3269@lukather> <1436186494.25646.72.camel@citrix.com> <20150706141002.GP3269@lukather> <1436192610.25646.98.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0619242242854623992==" Return-path: In-Reply-To: <1436192610.25646.98.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Thomas Petazzoni , Boris Brezillon , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============0619242242854623992== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z3PcgjD2qOzdkXVS" Content-Disposition: inline --z3PcgjD2qOzdkXVS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > > > >=20 > > > > On Mon, Jul 06, 2015 at 12:53:49PM +0100, Ian Campbell wrote: > > > > > (switching to my work address)=20 > > > > >=20 > > > > > On Thu, 2015-07-02 at 13:13 +0200, Maxime Ripard wrote: > > > > > > Hi, > > > > > >=20 > > > > > > I've started using Xen on an Allwinner A33, which works great a= s an > > > > > > headless device using the latest PSCI patches in U-Boot. > > > > > >=20 > > > > > > However, we would like to do something more with it, and we wou= ld need > > > > > > to have two VMs accessing the display at once, each one drawing= in its > > > > > > own part of the framebuffer. > > > > > >=20 > > > > > > Something that would look like this: > > > > > >=20 > > > > > > Framebuffer > > > > > > +---------------+ > > > > > > | | > > > > > > | Guest 1 | > > > > > > | | > > > > > > +---------------+ > > > > > > | | > > > > > > | | > > > > > > | | > > > > > > | Guest 2 | > > > > > > | | > > > > > > | | > > > > > > | | > > > > > > +---------------+ > > > > > >=20 > > > > > > Where thing start to get interesting is that the second guest w= ould be > > > > > > running Android, and as such would need OpenGL support, and acc= ess 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 men= u. > > > > > >=20 > > > > > > 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 do= m0. > > > > > >=20 > > > > > > 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 t= he > > > > > > system. > > > > > >=20 > > > > > > This way, we would also have a fixed size framebuffer assigned = to > > > > > > Android, which is much easier to support, and since we have tot= al > > > > > > control over the application in the first guest, we would be ab= le to > > > > > > control how much "transparency" we want to leave (=3D=3D how mu= ch of > > > > > > Android do we want to be displayed), and we would be able to cr= eate > > > > > > our drop-down menu. > > > > > >=20 > > > > > > Now the hard part: is such a setup possible at all with Xen? Ca= n 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 accelerat= ion? > > > > >=20 > > > > > As it stands today Xen supports exposing a 2D only PV graphics de= vice > > > > > (called "pvfb", essentially a flat/linear framebuffer) to guests,= I > > > > > think this has limited 2D acceleration support let alone 3D suppo= rt. You > > > > > can also (at least in principal, i.e. if the hardware isn't too s= trange) > > > > > pass a GPU through to exactly one guest (often it's just dom0). > > > > >=20 > > > > > Some people have also (I think) managed to use pvfb to expose a r= eal > > > > > linear fb to a guest, e.g. a "surface" in the real GPU which is s= etup by > > > > > some more privileged domain. > > > > >=20 > > > > > 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 guest= s. > > > > >=20 > > > > > Are you expecting Guest 1 and Guest 2 to be isolated from each ot= her in > > > > > a secure way? Or is one considered to be more privileged than the= other? > > > >=20 > > > > I'd like to have both guests as isolated from each other as possibl= e. > > > >=20 > > > > But there's two sub-issues here actually: > > > >=20 > > > > 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 p= vfb > > > > run on a DRM/KMS plane, that would be perfect for us. Another solut= ion > > > > would be to split the framebuffer in half and have pvfb running on > > > > those two halves. > > >=20 > > > Right, this portion is a bit more tractable in the short term I think. > > >=20 > > > > 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 dom= 0, > > > > but one of the domU's that would access it). > > >=20 > > > 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. > >=20 > > 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. > >=20 > > I don't know whether it makes sense... >=20 > 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 =66rom 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 --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --z3PcgjD2qOzdkXVS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVnj3rAAoJEBx+YmzsjxAg0asQALFghXIetB6EC7ppP6pNenTT w3RKIpOy1oluOqRY0LfuSVA1CZ6tOuVr+Pz9HChAEwhqDjNRqjXqlsQTEjeA22Zk cJfCk4yaCc0dRH8SAEhW0OyX8CUKkUR64Lt7X0gF66WSDjd12bT085DOj5AAH5vE YzVBqBIqm8TjC9KzpUs27kUHUAIWCedVxxlSIAC1/kjfopYrzsaLvRgvCwDzkqx6 il53u7zo4oc6IkPedIxawbZGomcjDFZmmhfhXc/puWr/hz0VdEkclk34XS5bJjNo Q8eNhlwg0DU928/8d9N7s3AfV5fO1Spz056JYtkREOqd/xJ6VbSloi7DLNZsKrQg Ns9cC5fBD9rBN1x+MTbMp+XFUpkpCfYnHt3eeT6rj+pkZ3nOcbzxTlqsgirPjq8L QYDs+YoqDsQ36jn4SXQmXQJ209/ti0P7VbqzIR6c75Xj2HLiy3fRoO58jnAeBw9h gg0pQhJh3PomQHqCxQNJsj3hyGLNqlbfBNDc5ulhRMRzH+GS0CmhgxNDl+98FxQD sVjkdrjltLl2sjChc2dcF4ErU3KtVqfYqvIVKGTOR7HEFbzLuDL7THjOpN2PV56G dNv/WJBSKZ1gg/VTII9umByCqYaIcEfT4GZDWY7QbdAtQRFuk9CNoIQm9LNtdzQ+ KNOiYbGSkYiNFsd2q7cK =fstD -----END PGP SIGNATURE----- --z3PcgjD2qOzdkXVS-- --===============0619242242854623992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0619242242854623992==--