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 thatI> 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 > athttp://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 useXen> 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, > DushmantaI 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@lists.xensource.com http://lists.xensource.com/xen-devel
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 thatI> 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 > athttp://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 useXen> 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, > DushmantaI 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@lists.xensource.com http://lists.xensource.com/xen-devel
Hello, Dushmanta Mohapatra, le Thu 03 Apr 2008 09:57:11 -0400, a écrit :> 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.That''s it.> I do not understand why originally the > back-end was not made a part of kernel like other devices?Why should it be? In the case of PVFB, he backend is responsible for actually showing the frame buffer. A userspace X11 application or VNC server is thus the logical way.> Also could you please tell me how to use this backend userspace tool.You just need to add vfb = [ ''type=sdl'' ] if you want to have an SDL window showing up when you start your domain, or vfb = [ ''type=vnc'' ] if you want to have a VNC server started instead.> 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.There is now the SDL choice.> 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.In the unstable tree, there is an OpenGL rendering which can accomodate with this by rescaling the frame buffer.> 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.Mmm, you may have a problem here, because PVFB uses Linux keycodes, not keysyms. I.e. whatever the configuration of the host machine, the guest keyboard configuration will be used.> 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)".That''s to get the initial size, but in the unstable tree we now have a PVFB event that permits the guest to change the size dynamically. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[Quoting fixed] "Dushmanta Mohapatra" <dushmanta.mohapatra@gmail.com> writes:> Markus Armbruster <armbru@redhat.com> writes: > > > "Dushmanta Mohapatra" <dmpatra@gmail.com> 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, > DushmantaHappy digging through the code! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks for the detailed reply. Makes the things a lot more clearer to me. But I have got a few more questions. How do I use the VNC/SDL to view domU''s console. I saw a thread http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html related to this and followed the approach. (I assume all the 10 patches mentioned in this series are available in Xen 3.2. Am I right?) In my domU config file I use options like this; vfb = [ ''type=sdl'' ] #vfb = [''type=vnc ''] #extra = "xencons=tty video=xenfb" extra = ''xencons=ttyS0 console=ttyS0 video=xenfb'' The domU starts booting and stops after printing some texts to the tty console (I think it waits for the back-end to come-up) Then I execute the command <qemu-dm -M xenpv -d domid>. Then a black screen flashes for a fraction of a second and goes away. Nothing happens. So am I doing the write things. Or am I supposed to do some thing different? (Do I need to start a VNC viewer in dom0 in case I am using the VNC option) in Xen 3.1 there was a tool vncfb . But that is missing in 3.2. I assume all of that functionality has been put into qemu-dm. In the thread http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html it is mentioned about merging xenfb and xenconsoled into qemu-dm. So what is the purpose of xenconsoled . If I look through my system I find binaries like (/usr/bin/xencons , /usr/sbin/xenconsoled /usr/lib64/xen/bin/xenconsole). Could you please give me an idea what are these used for? Finally a logistics question: Like you have said in your reply 2.6.18 kernel is not usable for many purposes. But Xen website does not provide support for any later version of kernel for dom0. Are the Xen guys planning to provide port for a later kernel like 2.6.23 /24? So I am wondering if I use the Xen that comes inbuilt with Linux distributions like Fedora8 do I get all the pvops features that you are mentioning? But I guess Fedora8 has Xen 3.1. And the current hypervisor is 3.2 . So all this make the whole thing a bit confusing. Thanks, Dushmanta _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Markus Armbruster wrote:> 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). >Ingo has taken it into his tree, and I don''t see anything blocking from going into 2.6.26 (you got the fb people to review it, right?). If you do an incremental patch to add resizing then we can add that too. BTW, does tablet mode work with the pvops patches? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge <jeremy@goop.org> writes:> Markus Armbruster wrote: >> 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). >> > > Ingo has taken it into his tree, and I don''t see anything blocking > from going into 2.6.26 (you got the fb people to review it, right?).Everything was cc: linux-fbdev-devel. The dependency on the fb defio fix was sorted out there. No comment from there otherwise; my code must be perfect ;)> If you do an incremental patch to add resizing then we can add that too.That''s the plan, but one step at a time.> BTW, does tablet mode work with the pvops patches? > > JI definitely should, as pvops'' xen-kbdfront is functionally equivalent to 2.6.18-xen''s xenkbd. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Dushmanta Mohapatra" <dushmanta.mohapatra@gmail.com> writes:> Thanks for the detailed reply. Makes the things a lot more clearer to me. > > But I have got a few more questions. > > How do I use the VNC/SDL to view domU''s console. I saw a thread > http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html > related to this and followed the approach. > (I assume all the 10 patches mentioned in this series are available in Xen > 3.2. Am I right?) > > In my domU config file I use options like this; > > vfb = [ ''type=sdl'' ] > #vfb = [''type=vnc ''] > #extra = "xencons=tty video=xenfb" > extra = ''xencons=ttyS0 console=ttyS0 video=xenfb''I''ve never tried video=xenfb, no idea what it does. I prefer to compile both xenfb and xenkbd in (not module). I don''t use any extra kernel arguments. But I use Fedora kernels and upstream kernels, not unpatched 2.6.18-xen.hg. The latter at some time needed and may still need: * xencons=xvc to stop the Xen console from mugging the serial console driver. * console=xvc to get a working console when PVFB is disabled. By default, only console tty is enabled, which is a useless dummy without PVFB. * console=xvc console=tty when PVFB is enabled, to enable both console tty (PVFB) and the Xen console xvc.> The domU starts booting and stops after printing some texts to the tty > console (I think it waits for the back-end to come-up) > > Then I execute the command <qemu-dm -M xenpv -d domid>. Then a black screen > flashes for a fraction of a second and goes away. > Nothing happens. So am I doing the write things. Or am I supposed to do some > thing different?Xend should start the backend automatically for you. If it doesn''t, check its log for hints on what went wrong. Also check qemu logs.> (Do I need to start a VNC viewer in dom0 in case I am using the VNC option)Yes. The VNC option makes more sense in most circumstances. For instance, closing the viewer window doesn''t kill your guest dead. If you use a distro that provides virt-manager (a GUI to control your virtual machines): virt-manager comes with an integrated viewer.> in Xen 3.1 there was a tool vncfb . But that is missing in 3.2. I assume all > of that functionality has been put into qemu-dm.Correct.> In the thread > http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html it > is mentioned about merging xenfb and xenconsoled into qemu-dm. So what is > the purpose of xenconsoled . If I look through my system I find binaries > like (/usr/bin/xencons , /usr/sbin/xenconsoled > /usr/lib64/xen/bin/xenconsole). Could you please give me an idea what are > these used for?xenconsoled receives logs from hypervisor and guests and writes them to log files, commonly in /var/lib/xen/> Finally a logistics question: > Like you have said in your reply 2.6.18 kernel is not usable for many > purposes. But Xen website does not provide support for any later version of > kernel for dom0. Are the Xen guys planning to provide port for a later > kernel like 2.6.23 /24?The pvops effort is about getting Xen kernel bits integrated into upstream Linux, so that we never again have to port them to later kernel versions.> So I am wondering if I use the Xen that comes inbuilt with Linux > distributions like Fedora8 do I get all the pvops features that you are > mentioning? But I guess Fedora8 has Xen 3.1. And the current hypervisor is > 3.2 . So all this make the whole thing a bit confusing. > > Thanks, > DushmantaThe Fedora 8 Xen kernel is a port to 2.6.21, but that''s pretty much as outdated and useless as .18. Fedora 9 and later will provide Xen through pvops in a *current* kernel. Hypervisor version and domU kernel version are not closely coupled. I would expect a pvops kernel guest to run fine both under a 3.1 and 3.2 hypervisor. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel