"Dushmanta Mohapatra" <dushmanta.mohapatra@xxxxxxxxx> writes:
> Markus Armbruster <armbru@xxxxxxxxxx> writes:
> > "Dushmanta Mohapatra" <dmpatra@xxxxxxxxx> writes:
> >> Hello,
> >> I am Dushmanta, a PhD student at Georgia Tech.
> >> I have been investigating about Xen Frame Buffer regarding a project that I
> >> am involved with.
> > I'm curious, can you tell me about it?
> >> I am facing some problems. So while searching on the net I found your post
> >> at http://lists.xensource.com/archives/html/xen-devel/2008-02/msg00717.html
> > This is the pvops para-virtual framebuffer (PVFB). The patch is for
> > Linus's tree.
> >> Now browsing through the source I find xenfb frontend related files at
> >> linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c (also xenkbd.c). (I use
> >> Xen
> >> 3.2 compiled from source).
> > This is the old, non-pvops Xen Linux tree.
> > This tree is much too old (2.6.18) to be useful for our users. We
> > used to extract the Xen patch from that tree and forward-port it to
> > less obsolete kernel versions, but that was not sustainable, so we
> > stopped.
> > The only future for Xen's Linux part, as far as I'm concerned, is
> > going upstream, into Linus's tree. That means porting it to the pvops
> > interface. Still a work in progress: domU is usable, but dom0 needs
> > more work. The patch you quoted above is part of that work in
> > progress.
> > I recommend to base any new work on pvops kernels, if at all
> > practical.
> >> So what exactly are the files you are referring to in your post.
> >> Also could you please give me a brief idea about the interaction between
> >> QEMU and xenfb in Xen 3.2 and what exactly has changed from Xen 3.1.
> >> Thanks,
> >> Dushmanta
> > I don't remember exact timing of changes. Peruse the Mercurial
> > repository.
> > PVFB consists of a frontend in domU (device driver in kernel space),
> > and a backend in dom0 user space.
> > The initial version implemented backend as a separate program (source
> > in xen-unstable.hg/tools/xenfb/). Later on, we merged it into QEMU,
> > chiefly to avoid having two different VNC servers.
> > If you have more questions, consider asking on the mailing list, where
> > more people than just you can profit from my answers :)
> > Markus
> Thanks for the response. It really helps. I have a few more questions.
> First of all I do not know what PVOPS means. I searched for it but did not
> find any thing convincing. So is that only for the official linux tree? In
> Xen website we still get the linux 2.6.18 kernel which gets patched for
> Xen. So for this 2.6.18 Xeno-Linux version do I need your patches for
> correct operation. Can I use the PVOPS tree at present for my Dom0? As far
> as I know only 2.6.18 version of Dom0 is currently available. I have read
> that we can use recent kernels like 2.6.23 etc for DomU though I myself use
> the same kernel for both Dom0 and DomU.
pvops is short for paravirt_ops. That's how the Linux kernel talks to
Hypervisors. Check out http://lwn.net/Articles/194543/ for a brief
linux-2.6.18-xen.hg is essentially a fork of Linux 2.6.18, which
predates pvops, modified for para-virtual Xen. 2.6.18 is much too old
to be useful in the real world (at least the one I inhabit).
linux-2.6.18-xen.hg contains a working PVFB.
Recent Linux kernels work for para-virtual domU, and people are
working hard to make them work fully for dom0.
I'm working on getting PVFB upstream, i.e. into the current Linux
kernel. I call that version of PVFB "pvops PVFB". It is cleaner and
smaller than what we have in linux-2.6.18-xen.hg, and has a bunch of
bugs fixed (all very unlikely to bite, but bugs still).
> I see two xenfb.c files in the Xen (3.2) source. One in tools/ioemu/hw/ and
> the other in linux-2.6.18-xen.hg/drivers/xen/fbfront/. So I think the first
> one is the userspace-backend and the second one is the kernel-space
> I do not understand why originally the back-end was not made a
> part of kernel like other devices? Also could you please tell me how to use
> this backend userspace tool. Any pointer will do.
Xend starts it on behalf of a domain that needs it. Start with
createDeviceModel() in tools/python/xen/xend/image.py.
Putting this backend into dom0 kernel space would make no sense,
because the service it provides to the frontend (acting as a VNC
server for it) can and really should be done entirely in user space.
> If I have understood it correctly then in Xen 3.1, this back end tool uses
> VNCServer for displaying the contents of Frontend frambuffer. So what
> has changed with the use of QEMU. Also I did not understand what you meant
> by "to avoid having two VNC servers".
> Is it related to one for FV and another for PV.
We used to use LibVNCServer for PVFB, and qemu-dm's VNC server
implementation for fully virtual domains. By integrating the PVFB
backend into qemu-dm, we got rid of the dependency on LibVNCServer.
Which is, by the way, among the most "interesting" pieces of code I
had the "privilege" to work with. Good riddance.
> Finally just to give you an idea about my project: Lets suppose a domU gets
> migrated from a Physical machine having a display of X1xY1 to another
> physical machine having a display of X2xY2. So our project tries to
> dynamically configure the front end/ back-end so that the user does not
> notice a difference. Also a similar example can be a domU getting migrated
> from a machine having one type of keyboard to a machine having another type
> of keyboard. So do you think support for this is already available in
> Xen 3.2. Are we doing some thing that others have already done? If I
> see Xen 3.2 code in the user space backend framebuffer code
> (/tools/ioemu/hw/xenfb.c) I see functions like "static int
> xenfb_read_frontend_fb_config(struct xenfb *xenfb)" and "static int
> xenfb_read_frontend_kbd_config(struct xenfb *xenfb)". So I am just wondering
> what these functions are for?
These are part of the Xenbus state machine. I don't think you should
mess with those.
The PVFB frontend supports the usual Linux framebuffer API for
dynamically changing resolutions. Check out xenfb_check_var() and
xenfb_set_par(). Actual resolution change is initiated by user space.
This is a fairly new feature, and I haven't merged it into pvops PVFB
yet, because I don't want to rock that boat right now by modifying the
patch (it's being reviewed and hopefully gets merged).
Different keyboards should just work. If you find some that don't, we
> I am sorry that the mail is a bit long. I really appreciate all your help.
Happy digging through the code!
Xen-devel mailing list