This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] virtualGraphicCards

To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] virtualGraphicCards
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 07 Sep 2005 14:31:19 -0500
Cc: "Retzki, Sascha \[Xplain\]" <sascha.retzki@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Daniel Hulme <dh286@xxxxxxxxx>
Delivery-date: Wed, 07 Sep 2005 19:29:24 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200509071558.56640.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <3AF26F5605627543BEC429636A5222900B7275@xxxxxxxxxxxxxxxxxxxxxxx> <200509071558.56640.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050727)
Mark Williamson wrote:

The idea is that the graphical console will have "back/front" structure similar to the other devices, with a viewer in dom0 reading screen data from the guest and either displaying it, or exporting it over the network.

The question here is: do we write a kernel framebuffer driver for this (and get the X server to use that) or implement it in the X server directly? I think the former solution is probably going to have the best cost/benefit.
I agreed with Mark up until very recently. Doing some (unscientific) analysis of the cost of framebuffer rendering leads me to belief that it's not necessarily worth having a kernel framebuffer for para-virtual domains.

IMHO, a better solution would be to use Xvnc and have a terminal => VNC server (that could also proxy a VNC session). Here's how I think it would look:

Every domain has a dedicated network interface for VNC. Domains are configured with Xvnc with reverse VNC. Each domain has a XenVNC instance running on dom0, the XenVNC daemon either 1) exposes the console via VNC (perhaps with ggiterm) or 2) proxies the domain's Xvnc session.

Depending on where the device model ends up, for full virtual domains you can just expose the VNC session from the device model directly or proxy it in dom0.

The real benefit with this approach is you do the VNC encoding in the X server (and can take advantage of all of that information) as opposed to rendering to a flat buffer and then trying to expose that buffer directly. In fact, this is the only way to take advantage of the remote cursor pseudo-encodings in VNC which IMO has the most dramatic effect on VNC usability.

Just a thought.


Anthony Liguori

One thing that's important (IMHO) is not to require networking in order to get the virtual display - makes it easier to install, configure stuff, etc via a graphical interface.


Do you mean how the virtual graphics card is "seen" by the dom0? Or/And

Imho, a glue-layer could abstract several approaches, for example 9P
(the Plan9-folks love it, I did not have the time to test it and thus I
don't have an opinion yet. However, I believe it is good ;-)) and VNC,
and the dom0 decides itsself howto access the "data" - this would be
pretty good because some OSes (which may be dom0-cabable some day) may
find method-N better (are optimized for it) than method-M... and so on

Xen-devel mailing list

Xen-devel mailing list

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>