|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Xen frame buffer related
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.
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. 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.
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.
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?
I am sorry that the mail is a bit long. I really appreciate all your help.
Thanks, Dushmanta
Hello,
>
>
> 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?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|