[Quoting fixed]
"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
> >
> Hi,
>
> 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
introduction.
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
> front-end.
Correct.
> 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
take patches.
> I am sorry that the mail is a bit long. I really appreciate all your help.
>
> Thanks,
> Dushmanta
Happy digging through the code!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home