[Qemu-devel] Re: [kvm-devel] Storing command line options in qcow2 images

2007-07-31 Thread Laurent Vivier 
Jorge Lucángeli Obes wrote:
[...]
 Laurent, do you want the patches for the functionality that's working
 right now? We can divide the (not very big amount of) work that's
 left. It consists basically on teaching qemu how to look for command
 line options, if none are present on the current invocation. I don't
 mind doing it by myself if you want to keep working on the other stuff
 you've been posting patches about.

Yes, send me your patches and tell me what I can do for you.

Regards,
Laurent
-- 
- [EMAIL PROTECTED]  --
  Software is hard - Donald Knuth



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Re: [kvm-devel] Storing command line options in qcow2 images

2007-07-31 Thread Jorge Lucángeli Obes 
On 7/30/07, Avi Kivity [EMAIL PROTECTED] wrote:
 Jorge Lucángeli Obes wrote:
  Hi Avi, hi all,

 I believe that Laurent (copied) is also interested in this area.

Copied him.

  I've started some (very minor) groundwork for this task. My idea was
  to add an extra annotation field in qcow2 snapshots. In this way, a
  snapshot can hold abitrary information; for example, command line
  arguments.
 
  Before going any further, I wanted to validate the general idea with
  the list.

 I've copied qemu-devel as well.  This can benefit qemu as much as kvm
 and I see no reasons that this shouldn't be merged into kvm through qemu
 upstream.  Furthermore, I'd very much hate to see qemu and kvm image
 formats diverge, so I'd like to get the qemu maintainer's approval for
 any format changes or extensions.

Agreed.

  There's a slight overhead as now all qcow2 snapshots have to store a
  extra (probably) empty pointer. An alternative approach would be to
  somehow indicate that some snapshots are descriptive snapshots and
  others are useful snapshots; however, I felt that this would be more
  complicated.
 

 Will storing an extra pointer break existing qcow2 images?   If so, we'd
 better avoid it.

It could be a problem, I agree. Maybe it's a better idea not to touch
the on-disk format. That would mean leaving 'struct
QCowSnapshotHeader' intact, and using existing fields to store our
information. The header includes an extra_data_size field that can
do the trick. This would of course need approval from qemu developers.

Laurent, do you want the patches for the functionality that's working
right now? We can divide the (not very big amount of) work that's
left. It consists basically on teaching qemu how to look for command
line options, if none are present on the current invocation. I don't
mind doing it by myself if you want to keep working on the other stuff
you've been posting patches about.

Just to be clear, the actual embedding of command line options into
the image would be done with qemu-img. It would be qemu's job to
validate this when the image is loaded.

Another way to do this could be to add an option to qemu that does the
embedding. This would have the benefit of free option validation, but
I felt that image-related operations should be used from qemu-img.

Cheers,
Jorge

[Qemu-devel] Patch: fix init of old_exception

2007-07-31 Thread Bernhard Kauer 
The old_exception field is initialized on startup with 0.
Therefore the very first fault (e.g. #GP) could be converted
to a double fault on an application processor. The attached
patch initialize old_exception on every CPU reset with -1.


Bernhard Kauer
Index: target-i386/helper2.c
===
RCS file: /sources/qemu/qemu/target-i386/helper2.c,v
retrieving revision 1.47
diff -u -r1.47 helper2.c
--- target-i386/helper2.c	17 Apr 2007 23:08:56 -	1.47
+++ target-i386/helper2.c	31 Jul 2007 14:30:55 -
@@ -155,6 +155,8 @@
 
 tlb_flush(env, 1);
 
+env-old_exception = -1;
+
 /* init to reset state */
 
 #ifdef CONFIG_SOFTMMU

[Qemu-devel] Patch: PIC-i8259 mode transition wrong

2007-07-31 Thread Bernhard Kauer 
The PIC initilization should respect the fourth byte init
bit in single mode.


Bernhard Kauer
Index: hw/i8259.c
===
RCS file: /sources/qemu/qemu/hw/i8259.c,v
retrieving revision 1.22
diff -u -r1.22 i8259.c
--- hw/i8259.c	7 Apr 2007 18:14:41 -	1.22
+++ hw/i8259.c	31 Jul 2007 14:31:14 -
@@ -351,7 +351,7 @@
 break;
 case 1:
 s-irq_base = val  0xf8;
-s-init_state = s-single_mode  s-init4 ? 3 : 2;
+s-init_state = s-single_mode ? (s-init4 ? 3 : 0) : 2;
 break;
 case 2:
 if (s-init4) {

[Qemu-devel] PATCH 0/8: Authentication support for the VNC server

2007-07-31 Thread Daniel P. Berrange 
The current VNC server implementation does not have support for the
authentication of incoming client connections. The following series
of patches provide support for a number of alternatives, all compliant
with the VNC protocol spec. The simplest mechanism (and the weakest)
is the traditional VNC password scheme based on weak d3des hashing of
an 8 byte key. The more serious mechanism uses TLS for data encryption
of the entire session, and x509 certificates for both client and server
authentication.

The patches are an iteration on the previous work I posted a couple of
months ago[1]. They are now functionally complete, better tested,
split up into a patch series for easier review, and their use fully
documented. Since TLS can be quite perplexing, I also included some
documentation on how to setup a CA, and issue client  server certs
in a manner suitable for use with the VNC server.

For the basic VNC password auth, this patch should be compatible with
any standard VNC client such as RealVNC. The TLS based auth schemes
require a client that implements the VeNCrypt extension[2]. The client
from the VeNCrypt[3] project of course is one example. The GTK-VNC[4]
widget which is used by Virt Manager[5] and Vinagre [6] also support
it, and are my primary testing platform.

The 8 individual patches will follow shortly in replies to this mail.

Regards,
Dan.

[1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg08616.html
[2] http://www.mail-archive.com/qemu-devel@nongnu.org/msg08681.html
[3] http://sourceforge.net/projects/vencrypt/
[4] http://gtk-vnc.sourceforge.net/
[5] http://virt-manager.org/
[6] http://www.gnome.org/~jwendell/vinagre/
-- 
|=- 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  -=|

Re: [Qemu-devel] PATCH 1/8: Refactor VNC server setup API

2007-07-31 Thread Daniel P. Berrange 
This patch splits the vnc_display_init function into two parts,
the resulting vnc_display_init function merely initializes a
little state. The new vnc_display_open function is responsible
for starting the server. This refactoring is in preparation for
the next patch.

diff -r cdd882fa7018 vl.c
--- a/vl.c  Wed Jul 25 11:13:43 2007 -0400
+++ b/vl.c  Tue Jul 31 10:37:39 2007 -0400
@@ -7932,7 +7932,9 @@ int main(int argc, char **argv)
 /* nearly nothing to do */
 dumb_display_init(ds);
 } else if (vnc_display != NULL) {
-vnc_display_init(ds, vnc_display);
+vnc_display_init(ds);
+if (vnc_display_open(ds, vnc_display)  0)
+exit(1);
 } else {
 #if defined(CONFIG_SDL)
 sdl_display_init(ds, full_screen, no_frame);
diff -r cdd882fa7018 vl.h
--- a/vl.h  Wed Jul 25 11:13:43 2007 -0400
+++ b/vl.h  Tue Jul 31 10:34:10 2007 -0400
@@ -966,7 +966,9 @@ void cocoa_display_init(DisplayState *ds
 void cocoa_display_init(DisplayState *ds, int full_screen);
 
 /* vnc.c */
-void vnc_display_init(DisplayState *ds, const char *display);
+void vnc_display_init(DisplayState *ds);
+void vnc_display_close(DisplayState *ds);
+int vnc_display_open(DisplayState *ds, const char *display);
 void do_info_vnc(void);
 
 /* x_keymap.c */
diff -r cdd882fa7018 vnc.c
--- a/vnc.c Wed Jul 25 11:13:43 2007 -0400
+++ b/vnc.c Tue Jul 31 10:45:11 2007 -0400
@@ -73,7 +73,7 @@ struct VncState
 int last_x;
 int last_y;
 
-const char *display;
+char *display;
 
 Buffer output;
 Buffer input;
@@ -1169,7 +1169,58 @@ static void vnc_listen_read(void *opaque
 
 extern int parse_host_port(struct sockaddr_in *saddr, const char *str);
 
-void vnc_display_init(DisplayState *ds, const char *arg)
+void vnc_display_init(DisplayState *ds)
+{
+VncState *vs;
+
+vs = qemu_mallocz(sizeof(VncState));
+if (!vs)
+   exit(1);
+
+ds-opaque = vs;
+vnc_state = vs;
+vs-display = NULL;
+
+vs-lsock = -1;
+vs-csock = -1;
+vs-depth = 4;
+vs-last_x = -1;
+vs-last_y = -1;
+
+vs-ds = ds;
+
+if (!keyboard_layout)
+   keyboard_layout = en-us;
+
+vs-kbd_layout = init_keyboard_layout(keyboard_layout);
+if (!vs-kbd_layout)
+   exit(1);
+
+vs-ds-data = NULL;
+vs-ds-dpy_update = vnc_dpy_update;
+vs-ds-dpy_resize = vnc_dpy_resize;
+vs-ds-dpy_refresh = vnc_dpy_refresh;
+
+memset(vs-dirty_row, 0xFF, sizeof(vs-dirty_row));
+
+vnc_dpy_resize(vs-ds, 640, 400);
+}
+
+void vnc_display_close(DisplayState *ds)
+{
+VncState *vs = (VncState *)ds-opaque;
+
+if (vs-display) {
+   qemu_free(vs-display);
+   vs-display = NULL;
+}
+if (vs-lsock != -1) {
+   close(vs-lsock);
+   vs-lsock = -1;
+}
+}
+
+int vnc_display_open(DisplayState *ds, const char *arg)
 {
 struct sockaddr *addr;
 struct sockaddr_in iaddr;
@@ -1179,40 +1230,14 @@ void vnc_display_init(DisplayState *ds, 
 int reuse_addr, ret;
 socklen_t addrlen;
 const char *p;
-VncState *vs;
-
-vs = qemu_mallocz(sizeof(VncState));
-if (!vs)
-   exit(1);
-
-ds-opaque = vs;
-vnc_state = vs;
-vs-display = arg;
-
-vs-lsock = -1;
-vs-csock = -1;
-vs-depth = 4;
-vs-last_x = -1;
-vs-last_y = -1;
-
-vs-ds = ds;
-
-if (!keyboard_layout)
-   keyboard_layout = en-us;
-
-vs-kbd_layout = init_keyboard_layout(keyboard_layout);
-if (!vs-kbd_layout)
-   exit(1);
-
-vs-ds-data = NULL;
-vs-ds-dpy_update = vnc_dpy_update;
-vs-ds-dpy_resize = vnc_dpy_resize;
-vs-ds-dpy_refresh = vnc_dpy_refresh;
-
-memset(vs-dirty_row, 0xFF, sizeof(vs-dirty_row));
-
-vnc_dpy_resize(vs-ds, 640, 400);
-
+VncState *vs = (VncState *)ds-opaque;
+
+vnc_display_close(ds);
+if (strcmp(arg, none) == 0)
+   return 0;
+
+if (!(vs-display = strdup(arg)))
+   return -1;
 #ifndef _WIN32
 if (strstart(arg, unix:, p)) {
addr = (struct sockaddr *)uaddr;
@@ -1221,7 +1246,9 @@ void vnc_display_init(DisplayState *ds, 
vs-lsock = socket(PF_UNIX, SOCK_STREAM, 0);
if (vs-lsock == -1) {
fprintf(stderr, Could not create socket\n);
-   exit(1);
+   free(vs-display);
+   vs-display = NULL;
+   return -1;
}
 
uaddr.sun_family = AF_UNIX;
@@ -1235,40 +1262,53 @@ void vnc_display_init(DisplayState *ds, 
addr = (struct sockaddr *)iaddr;
addrlen = sizeof(iaddr);
 
+   if (parse_host_port(iaddr, arg)  0) {
+   fprintf(stderr, Could not parse VNC address\n);
+   free(vs-display);
+   vs-display = NULL;
+   return -1;
+   }
+
+   iaddr.sin_port = htons(ntohs(iaddr.sin_port) + 5900);
+
vs-lsock = socket(PF_INET, SOCK_STREAM, 0);
if (vs-lsock == -1) {
fprintf(stderr, Could not create socket\n);
-   exit(1);
+   free(vs-display);
+   vs-display = NULL;
+

Re: [Qemu-devel] PATCH 2/8: Extend monitor 'change' command for VNC

2007-07-31 Thread Daniel P. Berrange 
This patch extends the QEMU monitor 'change' command so that it can
be used to change the configuration of the VNC server. On the command
line the user can use -vnc none, and then issue the 'change vnc :1'
command later from the monitor. This is utilized in the next patch
to let the monitor fetch a password for the server. The concept could
also be extended to serial  parallel devices allowing changing of
their configuration on the fly.

diff -r e85f07144b6c monitor.c
--- a/monitor.c Tue Jul 31 10:53:15 2007 -0400
+++ b/monitor.c Tue Jul 31 10:55:31 2007 -0400
@@ -386,7 +386,7 @@ static void do_eject(int force, const ch
 eject_device(bs, force);
 }
 
-static void do_change(const char *device, const char *filename)
+static void do_change_block(const char *device, const char *filename)
 {
 BlockDriverState *bs;
 
@@ -399,6 +399,21 @@ static void do_change(const char *device
 return;
 bdrv_open(bs, filename, 0);
 qemu_key_check(bs, filename);
+}
+
+static void do_change_vnc(const char *target)
+{
+if (vnc_display_open(NULL, target)  0)
+   term_printf(could not start VNC server on %s\n, target);
+}
+
+static void do_change(const char *device, const char *target)
+{
+if (strcmp(device, vnc) == 0) {
+   do_change_vnc(target);
+} else {
+   do_change_block(device, target);
+}
 }
 
 static void do_screen_dump(const char *filename)
diff -r e85f07144b6c vnc.c
--- a/vnc.c Tue Jul 31 10:53:15 2007 -0400
+++ b/vnc.c Tue Jul 31 10:55:06 2007 -0400
@@ -1208,7 +1208,7 @@ void vnc_display_init(DisplayState *ds)
 
 void vnc_display_close(DisplayState *ds)
 {
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
 
 if (vs-display) {
qemu_free(vs-display);
@@ -1230,7 +1230,7 @@ int vnc_display_open(DisplayState *ds, c
 int reuse_addr, ret;
 socklen_t addrlen;
 const char *p;
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
 
 vnc_display_close(ds);
 if (strcmp(arg, none) == 0)

-- 
|=- 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  -=|

Re: [Qemu-devel] PATCH 3/8: VNC password authentication

2007-07-31 Thread Daniel P. Berrange 
This patch introduces support for VNC protocols upto 3.8 and with
it, support for password based authentication. VNC's password based
authentication is not entirely secure, but it is a standard and the
RFB spec requires that all clients support it. The password can be
provided by using the monitor 'change vnc :1' and it will prompt for
a password to be entered. Passwords have upto 8 letters of context.
Pressing 'enter' without entering any characters disables password
auth in the server. NB, we need a custom copy of d3des here because
VNC uses a 'special' modification of the algorithm. This d3des code
is public domain  in all other VNC servers  clients.

diff -r fccd2d79f407 Makefile.target
--- a/Makefile.target   Tue Jul 31 14:48:18 2007 -0400
+++ b/Makefile.target   Tue Jul 31 14:48:19 2007 -0400
@@ -479,7 +479,7 @@ ifdef CONFIG_SDL
 ifdef CONFIG_SDL
 VL_OBJS+=sdl.o x_keymap.o
 endif
-VL_OBJS+=vnc.o
+VL_OBJS+=vnc.o d3des.o
 ifdef CONFIG_COCOA
 VL_OBJS+=cocoa.o
 COCOA_LIBS=-F/System/Library/Frameworks -framework Cocoa -framework IOKit
@@ -540,7 +540,7 @@ sdl.o: sdl.c keymaps.c sdl_keysym.h
 sdl.o: sdl.c keymaps.c sdl_keysym.h
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
 
-vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h
+vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h d3des.c d3des.h
$(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $
 
 sdlaudio.o: sdlaudio.c
diff -r fccd2d79f407 d3des.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/d3des.c   Tue Jul 31 14:48:19 2007 -0400
@@ -0,0 +1,434 @@
+/*
+ * This is D3DES (V5.09) by Richard Outerbridge with the double and
+ * triple-length support removed for use in VNC.  Also the bytebit[] array
+ * has been reversed so that the most significant bit in each byte of the
+ * key is ignored, not the least significant.
+ *
+ * These changes are:
+ *  Copyright (C) 1999 ATT Laboratories Cambridge.  All Rights Reserved.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* D3DES (V5.09) -
+ *
+ * A portable, public domain, version of the Data Encryption Standard.
+ *
+ * Written with Symantec's THINK (Lightspeed) C by Richard Outerbridge.
+ * Thanks to: Dan Hoey for his excellent Initial and Inverse permutation
+ * code;  Jim Gillogly  Phil Karn for the DES key schedule code; Dennis
+ * Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau,
+ * for humouring me on.
+ *
+ * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.
+ * (GEnie : OUTER; CIS : [71755,204]) Graven Imagery, 1992.
+ */
+
+#include d3des.h
+
+static void scrunch(unsigned char *, unsigned long *);
+static void unscrun(unsigned long *, unsigned char *);
+static void desfunc(unsigned long *, unsigned long *);
+static void cookey(unsigned long *);
+
+static unsigned long KnL[32] = { 0L };
+
+static unsigned short bytebit[8]   = {
+   01, 02, 04, 010, 020, 040, 0100, 0200 };
+
+static unsigned long bigbyte[24] = {
+   0x80L,  0x40L,  0x20L,  0x10L,
+   0x8L,   0x4L,   0x2L,   0x1L,
+   0x8000L,0x4000L,0x2000L,0x1000L,
+   0x800L, 0x400L, 0x200L, 0x100L,
+   0x80L,  0x40L,  0x20L,  0x10L,
+   0x8L,   0x4L,   0x2L,   0x1L};
+
+/* Use the key schedule specified in the Standard (ANSI X3.92-1981). */
+
+static unsigned char pc1[56] = {
+   56, 48, 40, 32, 24, 16,  8,  0, 57, 49, 41, 33, 25, 17,
+9,  1, 58, 50, 42, 34, 26, 18, 10,  2, 59, 51, 43, 35,
+   62, 54, 46, 38, 30, 22, 14,  6, 61, 53, 45, 37, 29, 21,
+   13,  5, 60, 52, 44, 36, 28, 20, 12,  4, 27, 19, 11,  3 };
+
+static unsigned char totrot[16] = {
+   1,2,4,6,8,10,12,14,15,17,19,21,23,25,27,28 };
+
+static unsigned char pc2[48] = {
+   13, 16, 10, 23,  0,  4,  2, 27, 14,  5, 20,  9,
+   22, 18, 11,  3, 25,  7, 15,  6, 26, 19, 12,  1,
+   40, 51, 30, 36, 46, 54, 29, 39, 50, 44, 32, 47,
+   43, 48, 38, 55, 33, 52, 45, 41, 49, 35, 28, 31 };
+
+void deskey(key, edf)  /* Thanks to James Gillogly  Phil Karn! */
+unsigned char *key;
+int edf;
+{
+   register int i, j, l, m, n;
+   unsigned char pc1m[56], pcr[56];
+   unsigned long kn[32];
+
+   for ( j = 0; j  56; j++ ) {
+   l = pc1[j];
+   m = l  07;
+   pc1m[j] = (key[l  3]  bytebit[m]) ? 1 : 0;
+   }
+   for( i = 0; i  16; i++ ) {
+   if( edf == DE1 ) m = (15 - i)  1;
+   else m = i  1;
+   n = m + 1;
+   kn[m] = kn[n] = 0L;
+   for( j = 0; j  28; j++ ) {
+   l = j + totrot[i];
+   if( l  28 ) pcr[j] = pc1m[l];
+   else pcr[j] = pc1m[l - 28];
+

Re: [Qemu-devel] PATCH 4/8: VeNCrypt basic TLS support

2007-07-31 Thread Daniel P. Berrange 
This patch introduces minimal support for the VeNCrypt protocol
extension. This layers use of TLS (aka SSL) into the VNC data stream,
providing session encryption. This patch is the bare minimum protocol
support. It is enabled by using the 'tls' option flag eg -vnc :1,tls'
This is not secure on its own since it uses anonymous credentials.
The next patches will introduce x509 certificate credentials.

The configure script is setup to that TLS is only compiled in if the
--enable-vnc-tls flag is provided. This should avoid any breakage on
platforms without the GNU TLS libraries.

diff -r a1fa771c6cf9 Makefile.target
--- a/Makefile.target   Tue Jul 31 14:50:01 2007 -0400
+++ b/Makefile.target   Tue Jul 31 14:50:03 2007 -0400
@@ -402,6 +402,11 @@ endif
 endif
 AUDIODRV+= wavcapture.o
 
+ifdef CONFIG_VNC_TLS
+CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
+LIBS += $(CONFIG_VNC_TLS_LIBS)
+endif
+
 VL_OBJS += i2c.o smbus.o
 
 # SCSI layer
diff -r a1fa771c6cf9 configure
--- a/configure Tue Jul 31 14:50:01 2007 -0400
+++ b/configure Tue Jul 31 14:50:03 2007 -0400
@@ -89,6 +89,7 @@ fmod=no
 fmod=no
 fmod_lib=
 fmod_inc=
+vnc_tls=no
 bsd=no
 linux=no
 kqemu=no
@@ -252,6 +253,8 @@ for opt do
   ;;
   --fmod-inc=*) fmod_inc=$optarg
   ;;
+  --enable-vnc-tls) vnc_tls=yes
+  ;;
   --enable-mingw32) mingw32=yes ; cross_prefix=i386-mingw32- ; 
linux_user=no
   ;;
   --disable-slirp) slirp=no
@@ -362,6 +365,7 @@ echo   --enable-alsaenable 
 echo   --enable-alsaenable ALSA audio driver
 echo   --enable-fmodenable FMOD audio driver
 echo   --enable-dsound  enable DirectSound audio driver
+echo   --enable-vnc-tls enable TLS encryption for VNC server
 echo   --enable-system  enable all system emulation targets
 echo   --disable-system disable all system emulation targets
 echo   --enable-linux-user  enable all linux usermode emulation targets
@@ -589,6 +593,16 @@ fi # -z $sdl
 fi # -z $sdl
 
 ##
+# VNC TLS detection
+if test $vnc_tls = yes ; then
+  `pkg-config gnutls` || vnc_tls=no
+fi
+if test $vnc_tls = yes ; then
+  vnc_tls_cflags=`pkg-config --cflags gnutls`
+  vnc_tls_libs=`pkg-config --libs gnutls`
+fi
+
+##
 # alsa sound support libraries
 
 if test $alsa = yes ; then
@@ -675,6 +689,11 @@ fi
 fi
 echo FMOD support  $fmod $fmod_support
 echo OSS support   $oss
+echo VNC TLS support   $vnc_tls
+if test $vnc_tls = yes ; then
+echo TLS CFLAGS$vnc_tls_cflags
+echo TLS LIBS  $vnc_tls_libs
+fi
 if test -n $sparc_cpu; then
 echo Target Sparc Arch $sparc_cpu
 fi
@@ -845,6 +864,12 @@ if test $fmod = yes ; then
   echo CONFIG_FMOD_INC=$fmod_inc  $config_mak
   echo #define CONFIG_FMOD 1  $config_h
 fi
+if test $vnc_tls = yes ; then
+  echo CONFIG_VNC_TLS=yes  $config_mak
+  echo CONFIG_VNC_TLS_CFLAGS=$vnc_tls_cflags  $config_mak
+  echo CONFIG_VNC_TLS_LIBS=$vnc_tls_libs  $config_mak
+  echo #define CONFIG_VNC_TLS 1  $config_h
+fi
 qemu_version=`head $source_path/VERSION`
 echo VERSION=$qemu_version $config_mak
 echo #define QEMU_VERSION \$qemu_version\  $config_h
diff -r a1fa771c6cf9 vl.c
--- a/vl.c  Tue Jul 31 14:50:01 2007 -0400
+++ b/vl.c  Tue Jul 31 14:50:03 2007 -0400
@@ -6458,7 +6458,7 @@ void main_loop_wait(int timeout)
 if (FD_ISSET(ioh-fd, rfds)) {
 ioh-fd_read(ioh-opaque);
 }
-if (FD_ISSET(ioh-fd, wfds)) {
+if (!ioh-deleted  ioh-fd_write  FD_ISSET(ioh-fd, wfds)) {
 ioh-fd_write(ioh-opaque);
 }
 }
diff -r a1fa771c6cf9 vnc.c
--- a/vnc.c Tue Jul 31 14:50:01 2007 -0400
+++ b/vnc.c Tue Jul 31 14:50:03 2007 -0400
@@ -32,13 +32,25 @@
 #include keymaps.c
 #include d3des.h
 
-// #define _VNC_DEBUG
-
-#ifdef _VNC_DEBUG
+#if CONFIG_VNC_TLS
+#include gnutls/gnutls.h
+#include gnutls/x509.h
+#endif /* CONFIG_VNC_TLS */
+
+// #define _VNC_DEBUG 1
+
+#if _VNC_DEBUG
 #define VNC_DEBUG(fmt, ...) do { fprintf(stderr, fmt, ## __VA_ARGS__); } while 
(0)
+
+#if CONFIG_VNC_TLS  _VNC_DEBUG == 2
+static void debug_log(int level, const char* str) {
+VNC_DEBUG(%d %s, level, str);
+}
+#endif /* CONFIG_VNC_TLS  _VNC_DEBUG */
 #else
 #define VNC_DEBUG(fmt, ...) do { } while (0)
 #endif
+
 
 typedef struct Buffer
 {
@@ -76,6 +88,23 @@ enum {
 VNC_AUTH_TLS = 18,
 VNC_AUTH_VENCRYPT = 19
 };
+
+#if CONFIG_VNC_TLS
+enum {
+VNC_WIREMODE_CLEAR,
+VNC_WIREMODE_TLS,
+};
+
+enum {
+VNC_AUTH_VENCRYPT_PLAIN = 256,
+VNC_AUTH_VENCRYPT_TLSNONE = 257,
+VNC_AUTH_VENCRYPT_TLSVNC = 258,
+VNC_AUTH_VENCRYPT_TLSPLAIN = 259,
+VNC_AUTH_VENCRYPT_X509NONE = 260,
+VNC_AUTH_VENCRYPT_X509VNC = 261,
+VNC_AUTH_VENCRYPT_X509PLAIN = 262,
+};
+#endif /* CONFIG_VNC_TLS */
 
 struct VncState
 {
@@ -102,7 +131,15 @@ struct VncState
 char *display;
 char *password;
 int auth;
+#if CONFIG_VNC_TLS
+int subauth;
+#endif
 char

Re: [Qemu-devel] PATCH 5/8: x509 certificate for server

2007-07-31 Thread Daniel P. Berrange 
This patch adds support for using x509 certificates on the server
end. The server needs a CA certificate, and its own certificate and
private key. A CA revocation list is optional. This this patch the
file names are hardcoded. The next-but-one patch will make them
configurable.

The use of x509 certificates is controlled by the 'x509' flag to
the VNC arg, eg '-vnc :1,tls,x509'. This only provides encryption
of the session, no authentication.

diff -r b5430bd9f883 vnc.c
--- a/vnc.c Tue Jul 31 11:32:19 2007 -0400
+++ b/vnc.c Tue Jul 31 11:43:59 2007 -0400
@@ -104,6 +104,14 @@ enum {
 VNC_AUTH_VENCRYPT_X509VNC = 261,
 VNC_AUTH_VENCRYPT_X509PLAIN = 262,
 };
+
+#if CONFIG_VNC_TLS
+#define CA_FILE ca-cert.pem
+#define CRL_FILE ca-crl.pem
+#define KEY_FILE key.pem
+#define CERT_FILE cert.pem
+#endif
+
 #endif /* CONFIG_VNC_TLS */
 
 struct VncState
@@ -1369,16 +1377,59 @@ static gnutls_anon_server_credentials vn
 }
 
 
+static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(void)
+{
+gnutls_certificate_credentials_t x509_cred;
+int ret;
+struct stat st;
+
+if ((ret = gnutls_certificate_allocate_credentials(x509_cred))  0) {
+   VNC_DEBUG(Cannot allocate credentials %s\n, gnutls_strerror(ret));
+   return NULL;
+}
+if ((ret = gnutls_certificate_set_x509_trust_file(x509_cred, CA_FILE, 
GNUTLS_X509_FMT_PEM))  0) {
+   VNC_DEBUG(Cannot load CA certificate %s\n, gnutls_strerror(ret));
+   gnutls_certificate_free_credentials(x509_cred);
+   return NULL;
+}
+
+if ((ret = gnutls_certificate_set_x509_key_file (x509_cred, CERT_FILE, 
KEY_FILE,
+GNUTLS_X509_FMT_PEM))  0) 
{
+   VNC_DEBUG(Cannot load certificate  key %s\n, gnutls_strerror(ret));
+   gnutls_certificate_free_credentials(x509_cred);
+   return NULL;
+}
+
+if (stat(CRL_FILE, st)  0) {
+   if (errno != ENOENT) {
+   gnutls_certificate_free_credentials(x509_cred);
+   return NULL;
+   }
+} else {
+   if ((ret = gnutls_certificate_set_x509_crl_file(x509_cred, CRL_FILE, 
GNUTLS_X509_FMT_PEM))  0) {
+   VNC_DEBUG(Cannot load CRL %s\n, gnutls_strerror(ret));
+   gnutls_certificate_free_credentials(x509_cred);
+   return NULL;
+   }
+}
+
+gnutls_certificate_set_dh_params (x509_cred, dh_params);
+
+return x509_cred;
+}
+
 static int start_auth_vencrypt_subauth(VncState *vs)
 {
 switch (vs-subauth) {
 case VNC_AUTH_VENCRYPT_TLSNONE:
+case VNC_AUTH_VENCRYPT_X509NONE:
VNC_DEBUG(Accept TLS auth none\n);
vnc_write_u32(vs, 0); /* Accept auth completion */
vnc_read_when(vs, protocol_client_init, 1);
break;
 
 case VNC_AUTH_VENCRYPT_TLSVNC:
+case VNC_AUTH_VENCRYPT_X509VNC:
VNC_DEBUG(Start TLS auth VNC\n);
return start_auth_vnc(vs);
 
@@ -1429,11 +1480,17 @@ static void vnc_handshake_io(void *opaqu
 vnc_continue_handshake(vs);
 }
 
+#define NEED_X509_AUTH(vs)   \
+((vs)-subauth == VNC_AUTH_VENCRYPT_X509NONE ||   \
+ (vs)-subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
+ (vs)-subauth == VNC_AUTH_VENCRYPT_X509PLAIN)
+
+
 static int vnc_start_tls(struct VncState *vs) {
 static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
 static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
GNUTLS_SSL3, 0 };
 static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-gnutls_anon_server_credentials anon_cred = NULL;
+static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
 
 VNC_DEBUG(Do TLS setup\n);
 if (vnc_tls_initialize()  0) {
@@ -1454,7 +1511,7 @@ static int vnc_start_tls(struct VncState
return -1;
}
 
-   if (gnutls_kx_set_priority(vs-tls_session, kx_anon)  0) {
+   if (gnutls_kx_set_priority(vs-tls_session, NEED_X509_AUTH(vs) ? 
kx_x509 : kx_anon)  0) {
gnutls_deinit(vs-tls_session);
vs-tls_session = NULL;
vnc_client_error(vs);
@@ -1475,19 +1532,36 @@ static int vnc_start_tls(struct VncState
return -1;
}
 
-   anon_cred = vnc_tls_initialize_anon_cred();
-   if (!anon_cred) {
-   gnutls_deinit(vs-tls_session);
-   vs-tls_session = NULL;
-   vnc_client_error(vs);
-   return -1;
-   }
-   if (gnutls_credentials_set(vs-tls_session, GNUTLS_CRD_ANON, anon_cred) 
 0) {
-   gnutls_deinit(vs-tls_session);
-   vs-tls_session = NULL;
-   gnutls_anon_free_server_credentials(anon_cred);
-   vnc_client_error(vs);
-   return -1;
+   if (NEED_X509_AUTH(vs)) {
+   gnutls_certificate_server_credentials x509_cred = 
vnc_tls_initialize_x509_cred();
+   if (!x509_cred) {
+   gnutls_deinit(vs-tls_session);
+   vs-tls_session = NULL;
+   vnc_client_error(vs);
+

Re: [Qemu-devel] PATCH 6/8: x509 client certificate verification

2007-07-31 Thread Daniel P. Berrange 
This patch adds support for requesting and validating client certificates.
In effect the client certificates are being used as the authentication
mechansim, making VNC passwords unccessary, though using a combination of
both is also possible.

The verification of client certificates is enabled using the 'x509verify'
flag to VNC arg eg  '-vnc :1,tls,x509verify'

diff -r f8cd8bd742ee vnc.c
--- a/vnc.c Tue Jul 31 11:45:22 2007 -0400
+++ b/vnc.c Tue Jul 31 11:45:30 2007 -0400
@@ -37,7 +37,7 @@
 #include gnutls/x509.h
 #endif /* CONFIG_VNC_TLS */
 
-// #define _VNC_DEBUG 1
+ #define _VNC_DEBUG 1
 
 #if _VNC_DEBUG
 #define VNC_DEBUG(fmt, ...) do { fprintf(stderr, fmt, ## __VA_ARGS__); } while 
(0)
@@ -141,6 +141,7 @@ struct VncState
 int auth;
 #if CONFIG_VNC_TLS
 int subauth;
+int x509verify;
 #endif
 char challenge[VNC_AUTH_CHALLENGE_SIZE];
 
@@ -1418,6 +1419,85 @@ static gnutls_certificate_credentials_t 
 return x509_cred;
 }
 
+static int vnc_validate_certificate(struct VncState *vs)
+{
+int ret;
+unsigned int status;
+const gnutls_datum_t *certs;
+unsigned int nCerts, i;
+time_t now;
+
+VNC_DEBUG(Validating client certificate\n);
+if ((ret = gnutls_certificate_verify_peers2 (vs-tls_session, status))  
0) {
+   VNC_DEBUG(Verify failed %s\n, gnutls_strerror(ret));
+   return -1;
+}
+
+if ((now = time(NULL)) == ((time_t)-1)) {
+   return -1;
+}
+
+if (status != 0) {
+   if (status  GNUTLS_CERT_INVALID)
+   VNC_DEBUG(The certificate is not trusted.\n);
+
+   if (status  GNUTLS_CERT_SIGNER_NOT_FOUND)
+   VNC_DEBUG(The certificate hasn't got a known issuer.\n);
+
+   if (status  GNUTLS_CERT_REVOKED)
+   VNC_DEBUG(The certificate has been revoked.\n);
+
+   if (status  GNUTLS_CERT_INSECURE_ALGORITHM)
+   VNC_DEBUG(The certificate uses an insecure algorithm\n);
+
+   return -1;
+} else {
+   VNC_DEBUG(Certificate is valid!\n);
+}
+
+/* Only support x509 for now */
+if (gnutls_certificate_type_get(vs-tls_session) != GNUTLS_CRT_X509)
+   return -1;
+
+if (!(certs = gnutls_certificate_get_peers(vs-tls_session, nCerts)))
+   return -1;
+
+for (i = 0 ; i  nCerts ; i++) {
+   gnutls_x509_crt_t cert;
+   VNC_DEBUG (Checking certificate chain %d\n, i);
+   if (gnutls_x509_crt_init (cert)  0)
+   return -1;
+
+   if (gnutls_x509_crt_import(cert, certs[i], GNUTLS_X509_FMT_DER)  0) {
+   gnutls_x509_crt_deinit (cert);
+   return -1;
+   }
+
+   if (gnutls_x509_crt_get_expiration_time (cert)  now) {
+   VNC_DEBUG(The certificate has expired\n);
+   gnutls_x509_crt_deinit (cert);
+   return -1;
+   }
+
+   if (gnutls_x509_crt_get_activation_time (cert)  now) {
+   VNC_DEBUG(The certificate is not yet activated\n);
+   gnutls_x509_crt_deinit (cert);
+   return -1;
+   }
+
+   if (gnutls_x509_crt_get_activation_time (cert)  now) {
+   VNC_DEBUG(The certificate is not yet activated\n);
+   gnutls_x509_crt_deinit (cert);
+   return -1;
+   }
+
+   gnutls_x509_crt_deinit (cert);
+}
+
+return 0;
+}
+
+
 static int start_auth_vencrypt_subauth(VncState *vs)
 {
 switch (vs-subauth) {
@@ -1464,6 +1544,16 @@ static int vnc_continue_handshake(struct
VNC_DEBUG(Handshake failed %s\n, gnutls_strerror(ret));
vnc_client_error(vs);
return -1;
+}
+
+if (vs-x509verify) {
+   if (vnc_validate_certificate(vs)  0) {
+   VNC_DEBUG(Client verification failed\n);
+   vnc_client_error(vs);
+   return -1;
+   } else {
+   VNC_DEBUG(Client verification passed\n);
+   }
 }
 
 VNC_DEBUG(Handshake done, switching to TLS data mode\n);
@@ -1547,6 +1637,11 @@ static int vnc_start_tls(struct VncState
vnc_client_error(vs);
return -1;
}
+   if (vs-x509verify) {
+   VNC_DEBUG(Requesting a client certificate\n);
+   gnutls_certificate_server_set_request (vs-tls_session, 
GNUTLS_CERT_REQUEST);
+   }
+
} else {
gnutls_anon_server_credentials anon_cred = 
vnc_tls_initialize_anon_cred();
if (!anon_cred) {
@@ -1808,6 +1903,7 @@ void vnc_display_close(DisplayState *ds)
 vs-auth = VNC_AUTH_INVALID;
 #if CONFIG_VNC_TLS
 vs-subauth = VNC_AUTH_INVALID;
+vs-x509verify = 0;
 #endif
 if (vs-lsock != -1) {
close(vs-lsock);
@@ -1842,10 +1938,14 @@ int vnc_display_open(DisplayState *ds, c
 options = display;
 while ((options = strchr(options, ','))) {
options++;
-   if (strncmp(options, tls, 3) == 0)
+   if (strncmp(options, tls, 3) == 0) {
tls = 1; /* Require TLS */
-   else if (strncmp(options, x509, 4) == 0)
+   } else if (strncmp(options, x509verify, 10) == 0) {
+   x509 = 1;
+

Re: [Qemu-devel] PATCH 7/8: command line args for x509 cert paths

2007-07-31 Thread Daniel P. Berrange 
This final code patch adds 4 new command line arguments to QEMU to allow the
certificate files to be specified. The '-x509cacert', '-x509cert' and '-x509key'
parameters are mandatory if the 'x509' or 'x509verify' flags are used when
setting up the VNC server. If the certificates are not provided, all client
authentication attempts will be rejected.

diff -r f38519b13575 vl.c
--- a/vl.c  Tue Jul 31 14:51:31 2007 -0400
+++ b/vl.c  Tue Jul 31 14:51:32 2007 -0400
@@ -6701,6 +6701,12 @@ static void help(int exitcode)
-no-reboot  exit instead of rebooting\n
-loadvm filestart right away with a saved state (loadvm in 
monitor)\n
   -vnc displaystart a VNC server on display\n
+#if CONFIG_VNC_TLS
+  -x509cacert FILE  x509 CA certificate for TLS services\n
+  -x509cacrl FILE   x509 CA certificate revocation list for TLS 
services\n
+  -x509cert FILEx509 public certificate for TLS services\n
+  -x509key FILE x509 private key for TLS services\n
+#endif
 #ifndef _WIN32
   -daemonize  daemonize QEMU after initializing\n
 #endif
@@ -6796,6 +6802,12 @@ enum {
 QEMU_OPTION_usbdevice,
 QEMU_OPTION_smp,
 QEMU_OPTION_vnc,
+#if CONFIG_VNC_TLS
+QEMU_OPTION_x509cacert,
+QEMU_OPTION_x509cacrl,
+QEMU_OPTION_x509cert,
+QEMU_OPTION_x509key,
+#endif
 QEMU_OPTION_no_acpi,
 QEMU_OPTION_no_reboot,
 QEMU_OPTION_show_cursor,
@@ -6889,6 +6901,12 @@ const QEMUOption qemu_options[] = {
 { usbdevice, HAS_ARG, QEMU_OPTION_usbdevice },
 { smp, HAS_ARG, QEMU_OPTION_smp },
 { vnc, HAS_ARG, QEMU_OPTION_vnc },
+#if CONFIG_VNC_TLS
+{ x509cacert, HAS_ARG, QEMU_OPTION_x509cacert },
+{ x509cacrl, HAS_ARG, QEMU_OPTION_x509cacrl },
+{ x509cert, HAS_ARG, QEMU_OPTION_x509cert },
+{ x509key, HAS_ARG, QEMU_OPTION_x509key },
+#endif
 
 /* temporary options */
 { usb, 0, QEMU_OPTION_usb },
@@ -7171,6 +7189,9 @@ int main(int argc, char **argv)
 int fds[2];
 const char *pid_file = NULL;
 VLANState *vlan;
+#if CONFIG_VNC_TLS
+const char *x509cacert = NULL, *x509cacrl = NULL, *x509cert = NULL, 
*x509key = NULL;
+#endif
 
 LIST_INIT (vm_change_state_head);
 #ifndef _WIN32
@@ -7648,6 +7669,20 @@ int main(int argc, char **argv)
case QEMU_OPTION_vnc:
vnc_display = optarg;
break;
+#if CONFIG_VNC_TLS
+   case QEMU_OPTION_x509cacert:
+   x509cacert = optarg;
+   break;
+   case QEMU_OPTION_x509cacrl:
+   x509cacrl = optarg;
+   break;
+   case QEMU_OPTION_x509cert:
+   x509cert = optarg;
+   break;
+   case QEMU_OPTION_x509key:
+   x509key = optarg;
+   break;
+#endif
 case QEMU_OPTION_no_acpi:
 acpi_enabled = 0;
 break;
@@ -7945,6 +7980,10 @@ int main(int argc, char **argv)
 dumb_display_init(ds);
 } else if (vnc_display != NULL) {
 vnc_display_init(ds);
+#if CONFIG_VNC_TLS
+if (vnc_set_x509_credentials(ds, x509cacert, x509cacrl, x509cert, 
x509key)  0)
+exit(1);
+#endif
 if (vnc_display_open(ds, vnc_display, NULL)  0)
 exit(1);
 } else {
diff -r f38519b13575 vl.h
--- a/vl.h  Tue Jul 31 14:51:31 2007 -0400
+++ b/vl.h  Tue Jul 31 14:51:32 2007 -0400
@@ -971,6 +971,13 @@ void vnc_display_close(DisplayState *ds)
 void vnc_display_close(DisplayState *ds);
 int vnc_display_open(DisplayState *ds, const char *display, const char 
*password);
 void do_info_vnc(void);
+#if CONFIG_VNC_TLS
+int vnc_set_x509_credentials(DisplayState *ds,
+const char *cacert,
+const char *cacrl,
+const char *cert,
+const char *key);
+#endif
 
 /* x_keymap.c */
 extern uint8_t _translate_keycode(const int key);
diff -r f38519b13575 vnc.c
--- a/vnc.c Tue Jul 31 14:51:31 2007 -0400
+++ b/vnc.c Tue Jul 31 14:51:32 2007 -0400
@@ -142,6 +142,11 @@ struct VncState
 #if CONFIG_VNC_TLS
 int subauth;
 int x509verify;
+
+char *x509cacert;
+char *x509cacrl;
+char *x509cert;
+char *x509key;
 #endif
 char challenge[VNC_AUTH_CHALLENGE_SIZE];
 
@@ -1378,36 +1383,50 @@ static gnutls_anon_server_credentials vn
 }
 
 
-static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(void)
+static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(VncState 
*vs)
 {
 gnutls_certificate_credentials_t x509_cred;
 int ret;
-struct stat st;
+
+if (!vs-x509cacert) {
+   VNC_DEBUG(No CA x509 certificate specified\n);
+   return NULL;
+}
+if (!vs-x509cert) {
+   VNC_DEBUG(No server x509 certificate specified\n);
+   return NULL;
+}
+if (!vs-x509key) {
+   VNC_DEBUG(No server private key specified\n);
+   return NULL;
+}
+

Re: [Qemu-devel] PATCH 8/8: document all VNC authentication options

2007-07-31 Thread Daniel P. Berrange 
This patch updates the user documentation to detail the new syntax
options for VNC server configuration. It moves all the display
related options into a combined logical section for clarity. It
documents the different deployment secenarios possible with the
new VNC server capabilities and their security. It also provides
a guide for setting up a certificate authority and issuing clients
and server with their certificates

diff -r 9e499876ee0e qemu-doc.texi
--- a/qemu-doc.texi Tue Jul 31 11:47:13 2007 -0400
+++ b/qemu-doc.texi Tue Jul 31 14:43:50 2007 -0400
@@ -129,6 +129,7 @@ Download the experimental binary install
 * pcsys_network::  Network emulation
 * direct_linux_boot::  Direct Linux Boot
 * pcsys_usb::  USB emulation
+* vnc_security::   VNC security
 * gdb_usage::  GDB usage
 * pcsys_os_specific::  Target OS specific information
 @end menu
@@ -243,6 +244,56 @@ Simulate an SMP system with @var{n} CPUs
 Simulate an SMP system with @var{n} CPUs. On the PC target, up to 255
 CPUs are supported.
 
[EMAIL PROTECTED] -audio-help
+
+Will show the audio subsystem help: list of drivers, tunable
+parameters.
+
[EMAIL PROTECTED] -soundhw card1,card2,... or -soundhw all
+
+Enable audio and selected sound hardware. Use ? to print all
+available sound hardware.
+
[EMAIL PROTECTED]
+qemu -soundhw sb16,adlib hda
+qemu -soundhw es1370 hda
+qemu -soundhw all hda
+qemu -soundhw ?
[EMAIL PROTECTED] example
+
[EMAIL PROTECTED] -localtime
+Set the real time clock to local time (the default is to UTC
+time). This option is needed to have correct date in MS-DOS or
+Windows.
+
[EMAIL PROTECTED] -pidfile file
+Store the QEMU process PID in @var{file}. It is useful if you launch QEMU
+from a script.
+
[EMAIL PROTECTED] -daemonize
+Daemonize the QEMU process after initialization.  QEMU will not detach from
+standard IO until it is ready to receive connections on any of its devices.
+This option is a useful way for external programs to launch QEMU without having
+to cope with initialization race conditions.
+
[EMAIL PROTECTED] -win2k-hack
+Use it when installing Windows 2000 to avoid a disk full bug. After
+Windows 2000 is installed, you no longer need this option (this option
+slows down the IDE transfers).
+
[EMAIL PROTECTED] -option-rom file
+Load the contents of file as an option ROM.  This option is useful to load
+things like EtherBoot.
+
[EMAIL PROTECTED] -name string
+Sets the name of the guest.  This name will be display in the SDL window
+caption.  The name will also be used for the VNC server.
+
[EMAIL PROTECTED] table
+
+Display options:
[EMAIL PROTECTED] @option
+
 @item -nographic
 
 Normally, QEMU uses SDL to display the VGA output. With this option,
@@ -257,21 +308,69 @@ available screen space. This makes the u
 available screen space. This makes the using QEMU in a dedicated desktop
 workspace more convenient.
 
[EMAIL PROTECTED] -vnc display
[EMAIL PROTECTED] -full-screen
+Start in full screen.
+
[EMAIL PROTECTED] -vnc display[,option[,option[,...]]]
 
 Normally, QEMU uses SDL to display the VGA output.  With this option,
 you can have QEMU listen on VNC display @var{display} and redirect the VGA
 display over the VNC session.  It is very useful to enable the usb
 tablet device when using this option (option @option{-usbdevice
 tablet}). When using the VNC display, you must use the @option{-k}
-option to set the keyboard layout if you are not using en-us.
-
[EMAIL PROTECTED] may be in the form @var{interface:d}, in which case 
connections
-will only be allowed from @var{interface} on display @var{d}. Optionally,
[EMAIL PROTECTED] can be omitted.  @var{display} can also be in the form
[EMAIL PROTECTED]:path} where @var{path} is the location of a unix socket to 
listen for
-connections on.
-
+option to set the keyboard layout if you are not using en-us. Available
+options for @var{display} are
+
[EMAIL PROTECTED] @code
+
[EMAIL PROTECTED] @var{interface:d}
+
+TCP connections will only be allowed from @var{interface} on display @var{d}.
+By convention the TCP port is [EMAIL PROTECTED] Optionally, @var{interface} can
+be omitted in which case the server will bind to all interfaces.
+
[EMAIL PROTECTED] @var{unix:path}
+
+Connections will be allowed over UNIX domain sockets where @var{path} is the
+location of a unix socket to listen for connections on.
+
[EMAIL PROTECTED] @var{none}
+
+VNC is initialized by not started. The monitor @code{change} command can be 
used
+to later start the VNC server.
+
[EMAIL PROTECTED] table
+
+Following the @var{display} value there may be one or more @var{option} flags
+separated by commas. Valid options are
+
[EMAIL PROTECTED] @code
+
[EMAIL PROTECTED] @var{tls}
+
+Require that client use TLS when communicating with the VNC server. This
+uses anonymous TLS credentials so is susceptible to a man-in-the-middle
+attack. It is recommended that this option be combined with either the
[EMAIL PROTECTED] or @var{x509verify} options.
+
[EMAIL PROTECTED]

[Qemu-devel] [PATCH] Avoid unneeded rebuilds

2007-07-31 Thread Stefan Weil 
Today, a change of the target list for a QEMU build (caused by
calling configure a second time) creates new files config-host.h
and */config.h. So make is forced to re-compile a lot of files
which depend on any of these two files - even when they did not
change anything but their time stamp.

A small patch for configure improves this behaviour. Both header
files are now saved before creating new ones. If nothing
changed, the backup is restored. This is standard for other makes,
for example Linux kernels.

It would be nice to see my patch applied to CVS HEAD.

Thanks,
Stefan



Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.150
diff -u -b -B -r1.150 configure
--- configure	26 Jul 2007 20:41:46 -	1.150
+++ configure	31 Jul 2007 19:10:46 -
@@ -699,6 +699,8 @@
 
 #echo Creating $config_mak and $config_h
 
+test -f $config_h  mv $config_h ${config_h}~
+
 echo # Automatically generated by configure - do not modify  $config_mak
 echo # Configured with: $0 $@  $config_mak
 echo /* Automatically generated by configure - do not modify */  $config_h
@@ -867,6 +869,8 @@
 
 echo #define CONFIG_UNAME_RELEASE \$uname_release\  $config_h
 
+test -f ${config_h}~  cmp -s $config_h ${config_h}~  mv ${config_h}~ $config_h
+
 for target in $target_list; do
 target_dir=$target
 config_mak=$target_dir/config.mak
@@ -915,6 +919,8 @@
 
 #echo Creating $config_mak, $config_h and $target_dir/Makefile
 
+test -f $config_h  mv $config_h ${config_h}~
+
 mkdir -p $target_dir
 mkdir -p $target_dir/fpu
 if test $target = arm-linux-user -o $target = armeb-linux-user ; then
@@ -1074,6 +1080,8 @@
 echo CONFIG_COCOA=yes  $config_mak
 fi
 
+test -f ${config_h}~  cmp -s $config_h ${config_h}~  mv ${config_h}~ $config_h
+
 done # for target in $targets
 
 # build tree in object directory if source path is different from current one

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)

2007-07-31 Thread Juergen Lock 
On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
 On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
  On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
   Hi,
  Hi,
   
   On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
  
 Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
   
   Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
   write-only. I think it's safe to assume that the real hardware returns
   the last written value in these addresses when reading, but in the
   documentation they are write-only.
  
  Yeah it was crashing in static int force_8bit_access_check_and_set
  in linux/drivers/pcmcia/cistpl.c, apparently while doing an
  GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
  Patched that (patch-pxa-gpsr, attached), and now the boot seems
  to be hanging somewhere in userland...
 
 Ok I set a breakpoint on do_execve and found that it was repeatedly
 calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
 looks like:
   Socket 0: empty
   Socket 1: ATA/IDE Fixed Disk
   1 ide   ide_cs 0hda 3  0
 and indeed in qemu it has the disk in socket 0.  Patched that
 (see patch-spitz-hda, attached), and now (well I also added an
 sd image since I got lots of
   pxa_sd_put_command: responce time out by jiffies (cmd=01)
 ) I at least get
   INIT: version 2.78 booting
   mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
 and when I hit ^c (btw, the left shift key does work, only the
 right one doesnt) it continues with
   INIT: Entering runlevel: 4
   INIT: Switching to runlevel: 6
   INIT: Sending processes the TERM signal
   umount: forced umount of /dev/ram1 failed!
   Can't find /dev in /etc/fstab
   umount: /proc: Device or resource busy
   Rebooting the system...
 and the kernel's last words on the serial console are
   flushing ide devices: 
   Restarting system.
   reboot the kernel (1)
   Reboot failed -- System halted
 
  Okay, time to sfdisk the hda image (it was empty :), boot with
 `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
 then try sfdisk:
   # sfdisk /dev/hda
   modprobe: modprobe: Can't locate module block-major-3
   /dev/hda: No such device or address
 
   sfdisk: cannot open /dev/hda read-write
 
  Hmm, some module not loaded?  looking around in /lib/modules/
 I see no obvious candidate, anyone have an idea?
 
  Okay, back to the akita image...  booting that to runlevel 2 or 4 now
 in fact gets me a login prompt on the serial console, and in runlevel 4
 I even see the gui splash screen flashing, but the gui doesnt
 start, and after a few iterations I get
   INIT: Id ln respawning too fast: disabled for 5 minutes
 ln is (grep ln /etc/inittab):
   ln:345:respawn:survive -l 6 /sbin/launch

Ok i now created a proper terrier hda image using the
http://www.trisoft.de/download/SLC3200SYSPART.zip
and now I get essentially the same behaviour as with the akita
image, and I can confirm the gui startup is crashing with
gawk (277): undefined instruction: pc=00023dd4
Code: e3130020 1d908100 1a00 eb0020d1 (ee103170) 
and
qpe (297): undefined instruction: pc=4044fc88
Code: ed81110a ee120180 ee00018e e5913008 (ee102170)
(repeated as init respawns it.)

 I also posted a FreeBSD qemu-devel port update,
http://docs.freebsd.org/cgi/mid.cgi?20070731201608.GA30162
using the 2007-07-31_05 snapshot with the pxa-gpsr and spitz-hda
patches added.

 So if anyone has an idea about the fpu emulation crashes I'd be
thankful.

 Cheers,
Juergen

[Qemu-devel] [PATCH] QEMU Mips Host

2007-07-31 Thread Stefan Weil 
Some parts for a working mips host are still missing
in QEMU CVS HEAD.

Here is a new patch which makes mips host work for
system emulation.

I tested it with i386-softmmu/qemu, mips-softmmu/qemu-system-mips
and mipsel-softmmu/qemu-system-mipsel running on
an emulated malta (big and little endian, 32 bit) machine.

I could not test it with 64 bit mips host.

User mode emulation does not work (it does not work with
i386 host, too).

These parts of my patch are essential to get a working emulation:

Makefile.target:
   compiler flags for mips op.o

dyngen-exec.h:
   declarations for PARAM1, PARAM2 and PARAM3
   declaration for GOTO_LABEL_PARAM

dyngen.c:
   fixes for gen_code() and relocation code

dyngen.h:
exec-all.h:
   I'm not sure whether these changes are needed.
   At least it works with the changes...

Stefan

Thiemo Seufer schrieb:
 Stefan Weil wrote:
 [snip]

 I cherrypicked the easy bits, and will look at the rest when I have
 more time.
 When I started to write MIPS host, I found it difficult to
 get all locations which needed new code. To make it easier for
 new ports, I changed sequences of #if ... #endif, #if ... #endif
 into #if ... #elif ... #elif ... #else #error #endif.

 Some of those folded unrelated things together, I committed a different
 patch based on yours.
 Most important was Johannes code for testandset and PARAMn.
 AFAICS that testandset implementation is broken, and I think
 mine is correct, maybe except for the +R vs. +m bit in the asm
 constraints.

 Did my implementation fail for you?
 The patch still includes your relocation code, but it is disabled
 and uses my own code. I had no time to check or try the differences.

 Then I gather there's no particular reason why my _PC16 reloc code
 is deleted in the patch.

 Thiemo
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.189
diff -u -b -B -r1.189 Makefile.target
--- Makefile.target	31 Jul 2007 01:45:35 -	1.189
+++ Makefile.target	31 Jul 2007 20:03:22 -
@@ -181,7 +185,7 @@
 endif
 
 ifeq ($(ARCH),mips)
-OP_CFLAGS+=-mabi=32 -G0 -fno-PIC -mno-abicalls -fomit-frame-pointer -fno-delayed-branch -Wa,-O0
+OP_CFLAGS += -G 0 -fomit-frame-pointer -fno-delayed-branch
 ifeq ($(WORDS_BIGENDIAN),yes)
 BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld
 else
Index: dyngen-exec.h
===
RCS file: /sources/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.36
diff -u -b -B -r1.36 dyngen-exec.h
--- dyngen-exec.h	8 May 2007 23:30:44 -	1.36
+++ dyngen-exec.h	31 Jul 2007 20:03:23 -
@@ -224,6 +224,16 @@
 #define PARAM1 ({ int _r; asm( : =r(_r) : 0 (__op_param1)); _r; })
 #define PARAM2 ({ int _r; asm( : =r(_r) : 0 (__op_param2)); _r; })
 #define PARAM3 ({ int _r; asm( : =r(_r) : 0 (__op_param3)); _r; })
+#elif defined(__mips__)
+/* On MIPS, parameters to a c expression are passed via the global pointer.
+ * We don't want that. */
+#define PARAMN(index) ({ register int _r; \
+asm(lui %0,%%hi(__op_param #index )\n\t \
+ori %0,%0,%%lo(__op_param #index ) \
+: =r(_r)); _r; })
+#define PARAM1 PARAMN(1)
+#define PARAM2 PARAMN(2)
+#define PARAM3 PARAMN(3)
 #else
 #if defined(__APPLE__)
 static int __op_param1, __op_param2, __op_param3;
@@ -271,7 +281,10 @@
 #define EXIT_TB() asm volatile (rts)
 #elif defined(__mips__)
 #define EXIT_TB() asm volatile (jr $ra)
-#define GOTO_LABEL_PARAM(n) asm volatile (.set noat; la $1,  ASM_NAME(__op_gen_label) #n ; jr $1; .set at)
+#define GOTO_LABEL_PARAM(n) asm volatile (\
+lui $2,%hi( ASM_NAME(__op_gen_label) #n )\n\t \
+ori $2,$2,%lo( ASM_NAME(__op_gen_label)#n )\n\t \
+jr $2)
 #else
 #error unsupported CPU
 #endif
Index: dyngen.c
===
RCS file: /sources/qemu/qemu/dyngen.c,v
retrieving revision 1.54
diff -u -b -B -r1.54 dyngen.c
--- dyngen.c	15 Jul 2007 16:56:08 -	1.54
+++ dyngen.c	31 Jul 2007 20:03:26 -
@@ -1661,6 +1661,30 @@
 #define INSN_RETURN 0x03e8
 #define INSN_NOP0x
 
+uint8_t *p = (void *)(p_end - 8);
+if (p == p_start) {
+error(empty code for %s, name);
+} else if (get32((uint32_t *)(p)) != INSN_RETURN) {
+error(jr ra expected near the end of %s, name);
+} else if (get32((uint32_t *)(p + 4)) != INSN_NOP) {
+error(nop expected at the end of %s, name);
+} else if ((get32((uint32_t *)(p_start))  16) == 0x3c1c 
+  (get32((uint32_t *)(p_start + 4))  16) == 0x279c 
+  get32((uint32_t *)(p_start + 8)) == 0x0399e021) {
+/* Skip prologue
+   lui  gp,nn
+   addiugp,gp,nn
+   addu gp,gp,t9 */
+p_start += 12;
+start_offset += 12;
+}
+copy_size = p -

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)

2007-07-31 Thread andrzej zaborowski 
On 31/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
 On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
  On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
   On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
Hi,
   Hi,
   
On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
  
  Anyway, boot now fails with:
 qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
 i.e. it is apparently expecting something there that is not yet
   
Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
write-only. I think it's safe to assume that the real hardware returns
the last written value in these addresses when reading, but in the
documentation they are write-only.
  
   Yeah it was crashing in static int force_8bit_access_check_and_set
   in linux/drivers/pcmcia/cistpl.c, apparently while doing an
   GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
   Patched that (patch-pxa-gpsr, attached), and now the boot seems
   to be hanging somewhere in userland...
 
  Ok I set a breakpoint on do_execve and found that it was repeatedly
  calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
  looks like:
Socket 0: empty
Socket 1: ATA/IDE Fixed Disk
1 ide   ide_cs 0hda 3  0
  and indeed in qemu it has the disk in socket 0.  Patched that
  (see patch-spitz-hda, attached), and now (well I also added an
  sd image since I got lots of
pxa_sd_put_command: responce time out by jiffies (cmd=01)
  ) I at least get
INIT: version 2.78 booting
mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
  and when I hit ^c (btw, the left shift key does work, only the
  right one doesnt) it continues with
INIT: Entering runlevel: 4
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
umount: forced umount of /dev/ram1 failed!
Can't find /dev in /etc/fstab
umount: /proc: Device or resource busy
Rebooting the system...
  and the kernel's last words on the serial console are
flushing ide devices:
Restarting system.
reboot the kernel (1)
Reboot failed -- System halted
 
   Okay, time to sfdisk the hda image (it was empty :), boot with
  `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
  then try sfdisk:
# sfdisk /dev/hda
modprobe: modprobe: Can't locate module block-major-3
/dev/hda: No such device or address
 
sfdisk: cannot open /dev/hda read-write
 
   Hmm, some module not loaded?  looking around in /lib/modules/
  I see no obvious candidate, anyone have an idea?
 
   Okay, back to the akita image...  booting that to runlevel 2 or 4 now
  in fact gets me a login prompt on the serial console, and in runlevel 4
  I even see the gui splash screen flashing, but the gui doesnt
  start, and after a few iterations I get
INIT: Id ln respawning too fast: disabled for 5 minutes
  ln is (grep ln /etc/inittab):
ln:345:respawn:survive -l 6 /sbin/launch

 Ok i now created a proper terrier hda image using the
 http://www.trisoft.de/download/SLC3200SYSPART.zip
 and now I get essentially the same behaviour as with the akita
 image, and I can confirm the gui startup is crashing with
 gawk (277): undefined instruction: pc=00023dd4
 Code: e3130020 1d908100 1a00 eb0020d1 (ee103170)

According to objdump this is:

   0:   e3130020tst r3, #32 ; 0x20
   4:   1d908100wldrwne wr8, [r0]
   8:   1a00bne 0x10
   c:   eb0020d1bl  0x8358
  10:   ee103170fixzr3, f0

So the last opcode is not an iWMMXt opcode and not XScale-specific,
but somehow it got generated by gcc, right?  (and if the gcc knew that
it's compiling for an iWMMXt enabled processor, there would be no fpu
insns)

So unless the idea is that the condition for bne was supposed to be
always false and the function at 0x8358 is supposed to not return,
it's the kernel's emulation fault.

Are you running the stock kernel? otherwise maybe some fpu emulation is missing.

With fpu this code would be:
   0:   e3130020tst r3, #32 ; 0x20
   4:   1d908100ldfned  f0, [r0]
   8:   1a00bne 0x10
   c:   eb0020d1bl  0x8358
  10:   ee103170fixzr3, f0

can you try this change:
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -840,7 +840,7 @@ void helper_set_cp15(CPUState *env, uint32_t insn, uint32_t
val)
 if (op2 == 0  crm == 1) {
 /* Changes cp0 to cp13 behavior, so needs a TB flush.  */
 tb_flush(env);
-env-cp15.c15_cpar = (val  0x3fff) | 2;
+env-cp15.c15_cpar = val  0x3fff;
 break;
 }
 goto bad_reg;

 and
 qpe (297): undefined instruction: pc=4044fc88
 Code: ed81110a ee120180 ee00018e e5913008 (ee102170)

[Qemu-devel] qemu configure

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:07:32

Modified files:
.  : configure 

Log message:
A variant of move-if-change, by Stefan Weil.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.150r2=1.151

[Qemu-devel] qemu/target-i386 helper2.c

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:09:18

Modified files:
target-i386: helper2.c 

Log message:
Initialize old_exception, by Bernhard Kauer.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemur1=1.47r2=1.48

[Qemu-devel] qemu/hw i8259.c

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:12:09

Modified files:
hw : i8259.c 

Log message:
Fix i8259 initialization, by Bernhard Kauer.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/i8259.c?cvsroot=qemur1=1.22r2=1.23

[Qemu-devel] qemu/hw cirrus_vga.c cirrus_vga_rop.h

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:26:00

Modified files:
hw : cirrus_vga.c cirrus_vga_rop.h 

Log message:
Cirrus transparent BITBLT (w/o color expand), by Hitoshi Osada.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/cirrus_vga.c?cvsroot=qemur1=1.25r2=1.26
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/cirrus_vga_rop.h?cvsroot=qemur1=1.1r2=1.2

[Qemu-devel] qemu Changelog Makefile Makefile.target block.c...

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:28:54

Modified files:
.  : Changelog Makefile Makefile.target block.c vl.h 
Added files:
.  : block-parallels.c 

Log message:
Parallels disk image support, by Alex Beregszaszi.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.137r2=1.138
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.120r2=1.121
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.189r2=1.190
http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.43r2=1.44
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.258r2=1.259
http://cvs.savannah.gnu.org/viewcvs/qemu/block-parallels.c?cvsroot=qemurev=1.1

[Qemu-devel] qemu/hw acpi.c

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:32:11

Modified files:
hw : acpi.c 

Log message:
Implement ACPI specs 3.0, 4.7.2.5, by Michael Hanselmann.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/acpi.c?cvsroot=qemur1=1.12r2=1.13

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)

2007-07-31 Thread Juergen Lock 
On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote:
 On 31/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
  On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
   On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
 Hi,
Hi,

 On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
   
   Anyway, boot now fails with:
  qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
  i.e. it is apparently expecting something there that is not yet

 Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
 write-only. I think it's safe to assume that the real hardware returns
 the last written value in these addresses when reading, but in the
 documentation they are write-only.
   
Yeah it was crashing in static int force_8bit_access_check_and_set
in linux/drivers/pcmcia/cistpl.c, apparently while doing an
GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
Patched that (patch-pxa-gpsr, attached), and now the boot seems
to be hanging somewhere in userland...
  
   Ok I set a breakpoint on do_execve and found that it was repeatedly
   calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
   looks like:
 Socket 0: empty
 Socket 1: ATA/IDE Fixed Disk
 1 ide   ide_cs 0hda 3  0
   and indeed in qemu it has the disk in socket 0.  Patched that
   (see patch-spitz-hda, attached), and now (well I also added an
   sd image since I got lots of
 pxa_sd_put_command: responce time out by jiffies (cmd=01)
   ) I at least get
 INIT: version 2.78 booting
 mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
   and when I hit ^c (btw, the left shift key does work, only the
   right one doesnt) it continues with
 INIT: Entering runlevel: 4
 INIT: Switching to runlevel: 6
 INIT: Sending processes the TERM signal
 umount: forced umount of /dev/ram1 failed!
 Can't find /dev in /etc/fstab
 umount: /proc: Device or resource busy
 Rebooting the system...
   and the kernel's last words on the serial console are
 flushing ide devices:
 Restarting system.
 reboot the kernel (1)
 Reboot failed -- System halted
  
Okay, time to sfdisk the hda image (it was empty :), boot with
   `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
   then try sfdisk:
 # sfdisk /dev/hda
 modprobe: modprobe: Can't locate module block-major-3
 /dev/hda: No such device or address
  
 sfdisk: cannot open /dev/hda read-write
  
Hmm, some module not loaded?  looking around in /lib/modules/
   I see no obvious candidate, anyone have an idea?
  
Okay, back to the akita image...  booting that to runlevel 2 or 4 now
   in fact gets me a login prompt on the serial console, and in runlevel 4
   I even see the gui splash screen flashing, but the gui doesnt
   start, and after a few iterations I get
 INIT: Id ln respawning too fast: disabled for 5 minutes
   ln is (grep ln /etc/inittab):
 ln:345:respawn:survive -l 6 /sbin/launch
 
  Ok i now created a proper terrier hda image using the
  http://www.trisoft.de/download/SLC3200SYSPART.zip
  and now I get essentially the same behaviour as with the akita
  image, and I can confirm the gui startup is crashing with
  gawk (277): undefined instruction: pc=00023dd4
  Code: e3130020 1d908100 1a00 eb0020d1 (ee103170)
 
 According to objdump this is:
 
0:   e3130020tst r3, #32 ; 0x20
4:   1d908100wldrwne wr8, [r0]
8:   1a00bne 0x10
c:   eb0020d1bl  0x8358
   10:   ee103170fixzr3, f0
 
 So the last opcode is not an iWMMXt opcode and not XScale-specific,
 but somehow it got generated by gcc, right?  (and if the gcc knew that
 it's compiling for an iWMMXt enabled processor, there would be no fpu
 insns)

I guess the guys at sharp just didn't realize their cpu had no fpu
or something :)  (Or that you can compile to use softfloats.)
 
 So unless the idea is that the condition for bne was supposed to be
 always false and the function at 0x8358 is supposed to not return,
 it's the kernel's emulation fault.
 
 Are you running the stock kernel? otherwise maybe some fpu emulation is 
 missing.

 I tried with the stock kernel too.  (I had used its config as a base.)
And as I said when I traced the kernel's fpu emulation code the
problem seemed to be unitialized registers...  It's weird.
 
 With fpu this code would be:
0:   e3130020tst r3, #32 ; 0x20
4:   1d908100ldfned  f0, [r0]
8:   1a00bne 0x10
c:   eb0020d1bl  0x8358
   10:   ee103170fixzr3, f0
 
 can you try this change:
 --- a/target-arm/helper.c
 +++ b/target-arm/helper.c
 @@ -840,7 +840,7 @@ void

[Qemu-devel] qemu dyngen-exec.h exec-all.h

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:46:55

Modified files:
.  : dyngen-exec.h exec-all.h 

Log message:
Fiddly dyngen bits for s390 host support, by Ulrich Hecht.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen-exec.h?cvsroot=qemur1=1.36r2=1.37
http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemur1=1.58r2=1.59

[Qemu-devel] qemu Makefile.target dis-asm.h disas.c s390-dis.c

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/31 23:44:21

Modified files:
.  : Makefile.target dis-asm.h disas.c 
Added files:
.  : s390-dis.c 

Log message:
s390 disassembler support, by Ulrich Hecht.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.190r2=1.191
http://cvs.savannah.gnu.org/viewcvs/qemu/dis-asm.h?cvsroot=qemur1=1.13r2=1.14
http://cvs.savannah.gnu.org/viewcvs/qemu/disas.c?cvsroot=qemur1=1.39r2=1.40
http://cvs.savannah.gnu.org/viewcvs/qemu/s390-dis.c?cvsroot=qemurev=1.1

Re: [Qemu-devel] [PATCH] S/390 host fixed

2007-07-31 Thread Thiemo Seufer 
Ulrich Hecht wrote:
 On Monday 30 July 2007 13:49, Ulrich Hecht wrote:
  S/390 host support has been broken for a long time (since 0.4.2 or
  something like that). I finally got around to fix it, adding
  disassembly support on the way.
 
 And here's an even better patch that also fixes non-i386 targets. MIPS 
 needs a little workaround to keep GCC from creating a jump table, 
 something that dyngen cannot handle. Alpha does not build because of an 
 ICE.

I committed the bits I were comfortable with, which left those:

[snip]
 @@ -300,7 +300,7 @@
  if [ $bsd = yes -o $darwin = yes -o $mingw32 = yes ] ; then
  AIOLIBS=
  else
 -AIOLIBS=-lrt
 +AIOLIBS=-lrt -lpthread

Why is this needed? Linux toolchains should add -lpthread implicitly.

[snip]
 diff -ruN qemu/target-alpha/op_helper.c qemu-s390/target-alpha/op_helper.c
 --- qemu/target-alpha/op_helper.c 2007-04-05 06:58:33.0 +
 +++ qemu-s390/target-alpha/op_helper.c2007-07-30 12:16:31.0 
 +
 @@ -1229,6 +1229,9 @@
  CPUState *saved_env;
  target_phys_addr_t pc;
  int ret;
 +#ifdef __s390__
 +retaddr = (void*)((unsigned long)retaddr  0x7fffUL);
 +#endif

All of those look weird. Is this a null-extension vs. sign-extension
issue?

[snip]
 diff -ruN qemu/target-i386/translate.c qemu-s390/target-i386/translate.c
 --- qemu/target-i386/translate.c  2007-06-26 08:35:18.0 +
 +++ qemu-s390/target-i386/translate.c 2007-07-30 13:57:39.0 +
 @@ -1795,7 +1795,11 @@
  case CC_OP_SUBW:
  case CC_OP_SUBL:
  case CC_OP_SUBQ:
 +#ifdef __s390__
 +func = NULL; /* does not work on S/390 for unknown reasons */
 +#else
  func = gen_jcc_sub[s-cc_op - CC_OP_SUBB][jcc_op];
 +#endif

Hum. It wold be good to know what happens here.

[snip]
 diff -ruN qemu/target-mips/op.c qemu-s390/target-mips/op.c
 --- qemu/target-mips/op.c 2007-06-25 17:34:33.0 +
 +++ qemu-s390/target-mips/op.c2007-07-30 13:34:08.0 +
 @@ -1616,6 +1616,18 @@
  
  void op_cfc1 (void)
  {
 +#ifdef __s390__
 +if(!T1)
 +T0 = (int32_t)env-fcr0;
 +else if(T1 == 25)
 +T0 = ((env-fcr31  24)  0xfe) | ((env-fcr31  23)  0x1);
 +else if(T1 == 26)
 +T0 = env-fcr31  0x0003f07c;
 +else if(T1 == 28)
 +T0 = (env-fcr31  0x0f83) | ((env-fcr31  22)  0x4);
 +else
 +T0 = (int32_t)env-fcr31;
 +#else

I guess this breaks when you _breathe_ at the compiler. Inventing
switch-table support in dyngen would be preferable (if possible...).


Thiemo

Re: [Qemu-devel] What is the best way to control qemu on a remote box?

2007-07-31 Thread Thiemo Seufer 
Michael Hanselmann wrote:
 On Fri, Jul 27, 2007 at 09:22:08AM -0700, n schembr wrote:
  Is system_powerdown a better way to stop the host?  Is
  system_powerdown a soft operation like the atx powersupply?  It did
  not work with  a smoothwall guest.
 
 It would, but is not implemented for x86. I've been working on it using
 ACPI, but gave up after an enquiry about IRQ handling on this list
 hasn't been answered and a related patch has been ignored.

I committed your patch, sorry for the delay.


Thiemo

[Qemu-devel] qemu configure

2007-07-31 Thread Thiemo Seufer 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/08/01 00:09:31

Modified files:
.  : configure 

Log message:
Also match s390x.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.151r2=1.152

Re: [Qemu-devel] [PATCH] S/390 host fixed

2007-07-31 Thread Paul Brook 
   void op_cfc1 (void)
   {
  +#ifdef __s390__
  +if(!T1)
  +T0 = (int32_t)env-fcr0;

 I guess this breaks when you _breathe_ at the compiler. Inventing
 switch-table support in dyngen would be preferable (if possible...).

Actually, I'm surprised this doesn't break on other hosts. Jump tables are 
death on all targets, I guess s390 gcc happens to use different heuristics 
for expanding switch statements.

I suspect making dyngen handle jump tables is not going to happen.

Paul

Re: [Qemu-devel] PATCH 2/8: Extend monitor 'change' command for VNC

2007-07-31 Thread Anthony Liguori 

Daniel P. Berrange wrote:

This patch extends the QEMU monitor 'change' command so that it can
be used to change the configuration of the VNC server. On the command
line the user can use -vnc none, and then issue the 'change vnc :1'
command later from the monitor. This is utilized in the next patch
to let the monitor fetch a password for the server. The concept could
also be extended to serial  parallel devices allowing changing of
their configuration on the fly.
  


I've had a very similar patch to this in my queue for a while now.  I 
definitely think this is the right thing to do.


Regards,

Anthony Liguori


diff -r e85f07144b6c monitor.c
--- a/monitor.c Tue Jul 31 10:53:15 2007 -0400
+++ b/monitor.c Tue Jul 31 10:55:31 2007 -0400
@@ -386,7 +386,7 @@ static void do_eject(int force, const ch
 eject_device(bs, force);
 }
 
-static void do_change(const char *device, const char *filename)

+static void do_change_block(const char *device, const char *filename)
 {
 BlockDriverState *bs;
 
@@ -399,6 +399,21 @@ static void do_change(const char *device

 return;
 bdrv_open(bs, filename, 0);
 qemu_key_check(bs, filename);
+}
+
+static void do_change_vnc(const char *target)
+{
+if (vnc_display_open(NULL, target)  0)
+   term_printf(could not start VNC server on %s\n, target);
+}
+
+static void do_change(const char *device, const char *target)
+{
+if (strcmp(device, vnc) == 0) {
+   do_change_vnc(target);
+} else {
+   do_change_block(device, target);
+}
 }
 
 static void do_screen_dump(const char *filename)

diff -r e85f07144b6c vnc.c
--- a/vnc.c Tue Jul 31 10:53:15 2007 -0400
+++ b/vnc.c Tue Jul 31 10:55:06 2007 -0400
@@ -1208,7 +1208,7 @@ void vnc_display_init(DisplayState *ds)
 
 void vnc_display_close(DisplayState *ds)

 {
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
 
 if (vs-display) {

qemu_free(vs-display);
@@ -1230,7 +1230,7 @@ int vnc_display_open(DisplayState *ds, c
 int reuse_addr, ret;
 socklen_t addrlen;
 const char *p;
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
 
 vnc_display_close(ds);

 if (strcmp(arg, none) == 0)

Re: [Qemu-devel] PATCH 3/8: VNC password authentication

2007-07-31 Thread Anthony Liguori 

Daniel P. Berrange wrote:

This patch introduces support for VNC protocols upto 3.8 and with
it, support for password based authentication. VNC's password based
authentication is not entirely secure, but it is a standard and the
RFB spec requires that all clients support it. The password can be
provided by using the monitor 'change vnc :1' and it will prompt for
a password to be entered. Passwords have upto 8 letters of context.
Pressing 'enter' without entering any characters disables password
auth in the server. NB, we need a custom copy of d3des here because
VNC uses a 'special' modification of the algorithm. This d3des code
is public domain  in all other VNC servers  clients.
  


I think it may be better to have a command to explicitly set the vnc 
password.  Issuing change vnc :1 just to change the password is a 
little awkward IMHO.



-
-vnc_write_u32(vs, 1); /* None */
-vnc_flush(vs);
-
-vnc_read_when(vs, protocol_client_init, 1);
+VNC_DEBUG(Client request protocol version %d.%d\n, vs-major, vs-minor);
+if (vs-major != 3 ||
+   (vs-minor != 3 
+vs-minor != 7 
+vs-minor != 8)) {
+   VNC_DEBUG(Unsupported client version\n);
+   vnc_write_u32(vs, VNC_AUTH_INVALID);
+   vnc_flush(vs);
+   vnc_client_error(vs);
+   return 0;
+}
  


A very popular VNC client uses 3.5 as the protocol version.  I believe 
the specification requires that 3.5 be treated at 3.3 because of that.


Regards,

Anthony Liguori

Re: [Qemu-devel] PATCH 4/8: VeNCrypt basic TLS support

2007-07-31 Thread Anthony Liguori 

Daniel P. Berrange wrote:

This patch introduces minimal support for the VeNCrypt protocol
extension. This layers use of TLS (aka SSL) into the VNC data stream,
providing session encryption. This patch is the bare minimum protocol
support. It is enabled by using the 'tls' option flag eg -vnc :1,tls'
This is not secure on its own since it uses anonymous credentials.
The next patches will introduce x509 certificate credentials.

The configure script is setup to that TLS is only compiled in if the
--enable-vnc-tls flag is provided. This should avoid any breakage on
platforms without the GNU TLS libraries.

diff -r a1fa771c6cf9 Makefile.target
--- a/Makefile.target   Tue Jul 31 14:50:01 2007 -0400
+++ b/Makefile.target   Tue Jul 31 14:50:03 2007 -0400
@@ -402,6 +402,11 @@ endif
 endif
 AUDIODRV+= wavcapture.o
 
+ifdef CONFIG_VNC_TLS

+CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
+LIBS += $(CONFIG_VNC_TLS_LIBS)
+endif
+
 VL_OBJS += i2c.o smbus.o
 
 # SCSI layer

diff -r a1fa771c6cf9 configure
--- a/configure Tue Jul 31 14:50:01 2007 -0400
+++ b/configure Tue Jul 31 14:50:03 2007 -0400
@@ -89,6 +89,7 @@ fmod=no
 fmod=no
 fmod_lib=
 fmod_inc=
+vnc_tls=no
 bsd=no
 linux=no
 kqemu=no
@@ -252,6 +253,8 @@ for opt do
   ;;
   --fmod-inc=*) fmod_inc=$optarg
   ;;
+  --enable-vnc-tls) vnc_tls=yes
+  ;;
   --enable-mingw32) mingw32=yes ; cross_prefix=i386-mingw32- ; 
linux_user=no
   ;;
   --disable-slirp) slirp=no
@@ -362,6 +365,7 @@ echo   --enable-alsaenable 
 echo   --enable-alsaenable ALSA audio driver

 echo   --enable-fmodenable FMOD audio driver
 echo   --enable-dsound  enable DirectSound audio driver
+echo   --enable-vnc-tls enable TLS encryption for VNC server
 echo   --enable-system  enable all system emulation targets
 echo   --disable-system disable all system emulation targets
 echo   --enable-linux-user  enable all linux usermode emulation targets
@@ -589,6 +593,16 @@ fi # -z $sdl
 fi # -z $sdl
 
 ##

+# VNC TLS detection
+if test $vnc_tls = yes ; then
+  `pkg-config gnutls` || vnc_tls=no
+fi
+if test $vnc_tls = yes ; then
+  vnc_tls_cflags=`pkg-config --cflags gnutls`
+  vnc_tls_libs=`pkg-config --libs gnutls`
+fi
+
+##
 # alsa sound support libraries


Since it's possible to probe for gnutls support, why not just enable it 
by default and disable it if it's not available?



diff -r a1fa771c6cf9 vl.c
--- a/vl.c  Tue Jul 31 14:50:01 2007 -0400
+++ b/vl.c  Tue Jul 31 14:50:03 2007 -0400
@@ -6458,7 +6458,7 @@ void main_loop_wait(int timeout)
 if (FD_ISSET(ioh-fd, rfds)) {
 ioh-fd_read(ioh-opaque);
 }
-if (FD_ISSET(ioh-fd, wfds)) {
+if (!ioh-deleted  ioh-fd_write  FD_ISSET(ioh-fd, wfds)) {
 ioh-fd_write(ioh-opaque);
 }
 }
  


I thought this was fixed already.  At any rate, it should be a separate 
patch.



+#if CONFIG_VNC_TLS
+ssize_t vnc_tls_push(gnutls_transport_ptr_t transport,
+const void *data,
+size_t len) {
+struct VncState *vs = (struct VncState *)transport;
+int ret, lastErrno;
  


s/lastErrno/last_errno/g


+ retry:
+ret = send(vs-csock, data, len, 0);
+lastErrno = errno;
+VNC_DEBUG(Send %d errno %d\n, ret, ret  0 ? lastErrno : 0);
+if (ret  0) {
+   if (lastErrno == EINTR)
+   goto retry;
+   errno = lastErrno;
+   return -1;
+}
+return ret;
+}
  


Regards,

Anthony Liguor

[Qemu-devel] RFE- snapshot data storage location configurable

2007-07-31 Thread dmc 
I have a pretty ugly patch against qemu 0.8 which allows the location of data 
used with the -snapshot feature to be somewhere other than /var/tmp.  I have a 
use-case where I am creating many gigabytes of changes to disk in snapshot mode. 
 When 0.9 came out, I looked, but it seemed less than trivial to update my 
patch, which was a pretty ugly hack to begin with.


I don't suppose anybody else thinks this would be a useful feature?  Or at least 
someone who can rattle off the top of their heads the sorts of things I should 
keep in mind while trying to put it together myself?


A further extension, which I would like, but is also more complex to add, would 
be the ability to specify -snapshot, _per device_.


thanks,

-dmc

[Qemu-devel] qemu/target-arm helper.c translate.c

2007-07-31 Thread Andrzej Zaborowski 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/08/01 02:31:55

Modified files:
target-arm : helper.c translate.c 

Log message:
Special-case iWMMXt register transfer insns, which are in ARM LDC2/STC2 
class.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemur1=1.19r2=1.20
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.53r2=1.54

[Qemu-devel] qemu/hw spitz.c

2007-07-31 Thread Andrzej Zaborowski 
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Andrzej Zaborowski balrog 07/08/01 02:41:33

Modified files:
hw : spitz.c 

Log message:
Move Spitz microdrive from first to second PCMCIA slot where it belongs.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.10r2=1.11