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