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 -=|
xen-qemu-machine.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home