WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Prototype to use QEMU for PV guest framebuffer

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Prototype to use QEMU for PV guest framebuffer
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Thu, 2 Aug 2007 01:00:50 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 01 Aug 2007 16:58:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8A87A9A84C201449A0C56B728ACF491E2600F4@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070727202844.GA8236@xxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E2600F4@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Sun, Jul 29, 2007 at 11:03:09PM +0100, Ian Pratt wrote:
> > 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. 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
> 
> It'll certainly be good to see the back of libvncserver.
> 
> Could you investigate whether this patch applies to qemu-dm easily
> enough?

The answer was yes & no :-)  Although we've got a separate target for
QEMU, there's still a bunch of stuff in the main vl.c that is specific
to HVM guests - the memory map initialization basically.

The way I've approached this problem is to define two QEMU machines

  $ ./ioemu/i386-dm/qemu-dm -M ?
  Supported machines are:
  xenfv      Xen Fullyvirtualized PC (default)
  xenpv      Xen Paravirtualized PC

The little bit of HVM specific stuff from vl.c I've moved into the machine 
specific init function in  hw/xenfv.c

As with my first prototype the hw/xenpv.c file provides a machine for Xen
paravirt guests which merely talks the PVFB protocol. The only change from
my previous patch is that it now does pixel swizzling if the guest display
depth is not the same as the QEMU display depth.

So, in summary this does look like it'll work fairly well for PVFB.  The
patch attached is my latest work-in-progress

 b/tools/ioemu/hw/xenfb.c             |  822 +++++++++++++++++++++++++++++++++++
 b/tools/ioemu/hw/xenfb.h             |   35 +
 b/tools/ioemu/hw/xenfv.c             |  258 ++++++++++
 b/tools/ioemu/hw/xenpv.c             |  157 ++++++
 tools/ioemu/Makefile.target          |    6 
 tools/ioemu/target-i386-dm/helper2.c |    3 
 tools/ioemu/vl.c                     |  242 ----------
 tools/ioemu/vl.h                     |    4 
 12 files changed, 1287 insertions(+), 240 deletions(-)



Taking this idea of using QEMU for PV services a little further it occured
to me that if we could figure out a way to get the bootloaders to be run
from QEMU instead of XenD then we would be able to interact with pygrub
remotely over the graphical VNC console - currently you can only use it 
over the text serial console on the local host. It might also require that
we have QEMU handling the guest console directly instead of xenconsoled.
ie so that QEMU could make the bootloader (pygrub) available on both VNC & 
a PTY at the same time. This would also mean the serial console could take 
advantage of QEMU's support for accessing it via UDP, or TCP, or TCP+telnet, 
as well as local PTYs.

Finally, I notice that ioemu/patches/qemu-dm disables the QEMU code which
lets you boot a linux kernel+initrd directly, instead of using the MBR
to run a bootloader. Is there any particular reason why this can't be made
to work for Xen HVM guests ? The ability to boot a kenrel+initrd directly
is very handy for some deployment & installation scenarios - eg to automate
an anaconda installer, passing in command line args to kickstart, without
needing to modify a CDROM iso, or use PXE.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Attachment: xen-qemu-machine.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>