On Thu, Aug 02, 2007 at 01:00:50AM +0100, Daniel P. Berrange wrote:
> On Sun, Jul 29, 2007 at 11:03:09PM +0100, Ian Pratt wrote:
> > 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.
Here's a further iteration of the patch which demonstrates how QEMU can
provide the guest console too. I launch it with this:
qemu-dm -M xenpv -d 6 -vnc :0 -serial pty
A couple of open issues
- QEMU doesn't let us poll() on write event for its character device sinks,
so in theory we could be loosing data if the pty were to give EAGAIN.
I think it should be possible to address this fairly easily.
- The xenconsoled has persistent logging of guest & HV. For the latter we
could just strip xenconsoled to merely provide HV logging, or even move
that into XenD since its such a tiny amount of code. For guest logging
QEMU can use '-serial file:/path' but then you can't use it via the pty
Probably could extend QEMU command line syntax '-serial pty;file:/path'
to open and PTY & log at the same time.
Those minor details aside though, this seems to work quite well - the code
is only 400 lines, compared to about 1200 lines in xenconsoled.
|=- 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 -=|
Description: Text document
Xen-devel mailing list