> So, dom0 sees the real graphics card, and attaches to it.
> Xen offers virtual graphics cards for each domU. domU_2 does not fire
> up 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?
I think it quite likely that each domain gets its own little framebuffer
in memory.
> 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)? Anyway the data is accessed, either in a
> "raw" way or through some "protocol" like VNC.
Makes sense.
> 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.
Exactly, so you support the first option Mark mentioned. The second
option is that we shift the boundary higher up than that: the domU just
has a special X driver that, instead of writing the data to a gfx card,
packages it up in whatever way for the backend driver in dom0 to look at
later. This is probably an easier way to do it -- we only have to
interface to X calls, rather than having to pretend to be a whole
graphics card, with VESA and everything -- but strikes me as being
almost cripplingly platform-specific.
This is still some way off, though, so everything is up in the air.
--
,^--^. ,-----. Never meddle in the affairs of angry cats,
( + + )----- ---' for they are well-armed and quick to bite.
/ -- ) http://surreal.istic.org/ keyid 885b170d
|_,-|_/--,_|-\_| I'm not complaining; I'm just commenting negatively.
pgpqrOgEGTAFK.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home