Re: [Xen-devel] virtualGraphicCards

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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

Yep.

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

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel