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: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] virtualGraphicCards
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 16:24:59 +0100
Cc: "Retzki, Sascha \[Xplain\]" <sascha.retzki@xxxxxxxxx>
Delivery-date: Wed, 07 Sep 2005 15:23:54 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <3AF26F5605627543BEC429636A5222900B72C1@xxxxxxxxxxxxxxxxxxxxxxx>
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: <3AF26F5605627543BEC429636A5222900B72C1@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
> I still don't get it, I'd like to make a little ASCII-art:
>    Xen
>    dom0 [graphical system]
>  -------------+----------------
>  domU_1 [graphical] domU_2 [text]

> So, dom0 sees the real graphics card, and attaches to it.


> Xen offers virtual graphics cards for each domU.

Not exactly: since Xen 2.0 all virtual devices are handled by dom0.  The guest 
accesses its virtual devices by "proxying" requests through dom0.  The 
virtual graphics device would work in a similar way...

> a graphical system, thus works with the emulated text buffer. domU_1
> fires up its graphical system. Both domU write some data to some place,
> managed by Xen (because Xen offered the vGraphicscard).
> 1.) Is the data actually saved as the domUs wrote them? Or is some
> glue-layer in-between, converting it to .e.g VNC-compatible data, to
> make the memory consumption problem go away?

The guests would be writing to some sort of "virtual framebuffer" memory.  
This memory would be read directly by *something* in dom0 to see what was 
being displayed.

> Anyway, if the dom0 wants to "see" any of domU, it just asks Xen for the
> data, getting a pointer or something (it just reads, anyway). It is best
> if we can interact with the domUs, so we get some virtual HIDs (Human
> Interface Devices)?

Yes, we'd need some sort of virtual HID layer.  This would want to basically 
connect the keyboard and mouse actions in the GUI to the guest, somehow.

> Anyway the data is accessed, either in a "raw" way 
> or through some "protocol" like VNC. Still, I don't see why any of the
> displaying systems, in the bottom (dom0 graphical system and/or Xen) or
> the top (domU graphical systems), and their transporting systems, should
> be known; In the end, all of those systems transfer data to a graphic
> card, in a standard way (VGA for instance), no matter if it is a linux
> framebuffer, a Unix x11, a Plan9 Rio, or any other system.

There's two possibilities:
1) emulate a VESA graphics card
2) write a special "Xen virtual" device, as we have for block, net, etc.

1 will possibly require some support from Xen.  The output in this case will 
be handled by a daemon in dom0 which will map the "framebuffer" memory and 
display it on the screen (in dom0).

2 is to just write another Xen-aware driver.  I suspect that explicitly 
writing a xen-aware display driver will prove easier and more scalable in 
future...  The guests "Xen display driver" will handle requests, draw into a 
"virtual framebuffer" and notify the dom0 daemon of changes, etc.

Either way, there's a component in dom0 that needs to read out this data and 
export it to the user.

The X server vs kernel framebuffer question refers to point 2: if we're going 
to implement a Xen-aware virtual framebuffer device, do we implement it as a 
kernel module or as an X server module?  I think the former makes more sense.

Does that answer your questions?


Xen-devel mailing list

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