"David Stone" <unclestoner@xxxxxxxxx> writes:
> Hi folks, I am hoping somebody could give an overview of the xen
> framebuffer/graphics architecture...at the level of what processes and
> drivers are involved in a Linux DomU and Dom0, how they are set up,
> how information control flows between them, etc. (Running 3.0.3, I
> see xen-vncfc in Dom0 and xenfb in domU).
>
> I'm primarily interested in understanding on how things work in a PV
> DomU, but also in a HVM DomU.
The PV framebuffer is an almost-ordinary split device driver[*]:
there's a frontend in domU and a backend in dom0, talking to each
other through Xenbus.
The frontend is a Linux device driver, living in drivers/xen/fbfront/.
Actually, it's a pair of drivers, one for the frame buffer (vfb), and
one for keyboard and mouse (vkbd, two devices).
Unlike other split drivers, the backend is in user space. It used to
be a separate program (either xen-vncfb or xen-sdlfb) under the
control of xend. It's been merged in qemu-dm recently, running under
the control of xend as for FV domains.
Communication between front- and backend is also somewhat peculiar.
The frontend shares the actual framebuffer with the frontend, and
notifies it of changes through Xenbus.
Hope this helps, feel free to ask more specific questions.
> I guess I'm not clear on why Xen has to do anything for this...doesn't
> xvnc provide a framebuffer that can be accessed via VNC, and wouldn't
> this be outside the scope of Xen?
Yeah, isn't it funny that we bother with a PV framebuffer when X is
fully network transparent? And stuff like NX makes it fast enough
even over slowish links? Basically, it's for convenience: it looks
like a plain frame buffer device in domU, no assembly required.
Especially appreciated by graphical installers.
> Thanks,
> Dave
[*] http://wiki.xensource.com/xenwiki/XenSplitDrivers
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home