From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Prototype to use QEMU for PV guest framebuffer Date: Fri, 27 Jul 2007 15:40:45 -0500 Message-ID: <46AA584D.3020005@codemonkey.ws> References: <20070727202844.GA8236@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070727202844.GA8236@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: > As many of us are all too painfully aware we have completely different VNC > server implementations for paravirt vs fullyvirt Xen guests. The former > based on libvncserver, the latter integrated into QEMU. There are many new > and interesting ideas being tried out in the VNC server space in particular > wrt to virtualization and having to implement them all twice is not very > desirable. Also libvncserver code is terrible - many bad thread race > conditions that are near impossible to diagnose, let alone solve :-( > > At the summit there were a couple of suggestions, either taking the VNC > server code from QEMU and splicing it into the xenfb daemon. Another was > to take the QEMU VNC code and put it into a library that can be used by > both QEMU & xenfb. Neither of those is a particularly appealing prospect. > > Then Anthony Liguori suggested a 3rd approach, which was to add a new QEMU > machine type to the x86 target, and simply disable all the emulated hardwre > and just make use of QEMU infrastructure for the VNC server, select() event > loop and display state. > > This sounded very intriguing so I did a little experimentation today doing > exactly that. First of all I've copied tools/xenfb/xenfb.c into the > qemu/hw/xenfb.c file. Next I added a qemu/hw/xen.c file to provide the > implementation of the QEMU machine type - called 'xenpv'. > > All the interesting code (all 100 lines of it) is in hw/xen.c in the > xen_init_pv method - which is called when using the '-M xenpv' command > line arg. > > The first thing this does is get the domain ID - to avoid touching QEMU's > command line args, I just use an environ variable XEN_DOMID to pass this > in. > > The main_loop() in qemu/vl.c assumes there is always one CPU created in > the VM, but for our purposes we're not doing any CPU emulation merely > using the event loop/display state. So to workaround this assumption I > create a single CPUState * instance, and permanently disable it by > setting 'cpu->hflags = HF_HALTED_MASK'. Seems to do the job. > > Next, up we attach to the guest PVFB frontend - just using the existing code > for this - qemu/hw/xenfb.c (formerly xen-unstable/tools/xenfb/xenfb.c). > > Now we register a QEMU graphical console, a mouse event receiver, a > keyboard event receiver, and register the xenstored and event channel > file handles with QEMU's event loop. > > Finally, initialize QEMU's display state to match the PVFB framebuffer > config (ie 800x600x32). > > Pushing mouse & keyboard events through from QEMU to PVFB frontend is > trivial. The only bit I'm unhappy about is that QEMU can't access the > guest framebuffer directly. The DisplayState * struct has its own copy > of the framebuffer - allocated by the VNC or SDL impls in QEMU - and > so whenever the guest framebuffer changes, we have to memcpy() the data > from the guest into the QEMU framebuffer. The DisplayState driver (VNC or SDL) chooses what the depth and format of this ds->data buffer should be. The PVFB expects a certain format so you would have to do more than just a memcpy(). You'll have to be able to translate between the xenfb format and the ds->data format. This is very cool stuff though! Since QEMU already supports VNC and SDL, we don't need to maintain any additional pvfb backends. Regards, Anthony Liguori > Still, this is no worse than > what the HVM guests already do. Its probably not too hard to change the > QEMU impl of VNC / SDL to use the guest framebuffer directly if we did > a little re-factoring. I wanted to keep it simple for now & not change > any of the upstream QEMU code. > > This attached patch is against the current upstream QEMU CVS code, not Xen's > ioemu, since I wanted to work against pristine QEMU codebase & avoid any > potential wierd iteractions with HVM stuff added to ioemu. The diff is