From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: stubdomain questions Date: Fri, 17 Jul 2009 11:55:46 -0400 Message-ID: <20090717155546.GM4874@const.linuxsymposium.org> References: <311d738a0907170834o4feaa6e2m2d8425ddac5c5376@mail.gmail.com> <311d738a0907170848g610250dft1f03ff2a2d3b21ad@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <311d738a0907170848g610250dft1f03ff2a2d3b21ad@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Giorgenes Gelatti Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Giorgenes Gelatti, le Fri 17 Jul 2009 12:48:34 -0300, a =E9crit : > when using stubdomains, qemu in dom0 doesn't do device emulation bu= t > provides few backends to the stubdom: the console backend and the p= vfb > backend. The last one is needed to render the guest framebuffer usi= ng > sdl or for exporting it through vnc. >=20 >=20 > Is it possible (or is it being planned) to put these functions inside t= he > stubdomain too and completely eliminate the need of qemu-dm running in = dom0? In theory we could compile SDL into the stubdomain and let it connect to the X server itself through TCP/IP. That however would be very far from efficient, as you loose memory-memory video blitting and go through network links. VNC server used to be possible in stubdomains, but the configuration is quite cumbersome: you have to assign the stubdomain an IP. Letting dom0 do this was much more simple, especially since dirtyness tracking is still done by the stubdomain, not dom0's ioemu. Samuel