[Qemu-devel] qemu/hw rtl8139.c

2007-08-01 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/08/01 13:10:29

Modified files:
hw : rtl8139.c 

Log message:
Fix rtl8139 checksum calculation, by Tim Deegan.

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




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

2007-08-01 Thread Ulrich Hecht
On Wednesday 01 August 2007 01:59, Thiemo Seufer wrote:
  -AIOLIBS=-lrt
  +AIOLIBS=-lrt -lpthread

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

Our SLES9 toolchain seems not to. It's a near-cosmetic change.

  +#ifdef __s390__
  +retaddr = (void*)((unsigned long)retaddr  0x7fffUL);
  +#endif

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

S/390 has a 31 (thirty-one) bit address space; the MSB of the PSW is not 
part of the address and must be masked out. This is simply part of the 
architecture, there's no way around it.

  +#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.

Indeed. :)

  +#ifdef __s390__
  +if(!T1)
  +T0 = (int32_t)env-fcr0;
  +else if(T1 == 25)
[...]

 I guess this breaks when you _breathe_ at the compiler.

Probably, but that is true for a significant part of the QEMU codebase...

CU
Uli

-- 
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)




Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)

2007-08-01 Thread Paul Brook
On Wednesday 01 August 2007, Dan Shearer wrote:
 On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote:
  I suspect making dyngen handle jump tables is not going to happen.

 Which brings up the question of dyngen. Very clever and a very good way
 of bootstrapping QEMU in the early days, but too brittle going forwards
 now the rest of QEMU works so well.

 You had an alternative approach to dyngen, pointed at here:
 http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00227.html

 Any thoughts about the future of hand-coded backends in QEMU? I wasn't
 convinced at first (and, given resources, it isn't nearly as good as a
 special-purpose language for describing CPUs at this level) but I now
 think your work is a very good solution for bootstrapping QEMU to the
 next level of users.

There's also a goolge SoC project to use llvm for code generation.
http://code.google.com/p/llvm-qemu/
This works, however it's also significantly slower than current qemu (no more 
than half the speed). It may be possible to improve this, but llvm is a 
fairly heavyweight framework so I'm not convinced it is ever going to be 
competitive for generalexecution speed.

One interesting thing that did come out of that project is that it's fairly 
trivial (a few hours work) to turn the existing code into a simple 
interpreter. Obviously this incurs a large performance hit, but also makes 
qemu trivially portable to other hosts.

My hand coded generator is currently ~20% slower that dyngen.
I still think this (or something similar) is the way forward, however I 
haven't made time to do any work on it recently. Some parts of this code 
effectively are a special language for describing a CPU, that happen to be 
implemented using the C preprocessor :-)

Paul




Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)

2007-08-01 Thread Paul Brook
On Wednesday 01 August 2007, Dan Shearer wrote:
 On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote:
  Some parts of this code effectively are a special language for
  describing a CPU, that happen to be implemented using the C
  preprocessor :-)

 Right, in the same way that QEMU devices written in C are in a device
 language? :-)

Not really. The cpu backends are mainly defining parameters for the generic 
code. Most of it doesn't look much like C.  The implementation of the code 
generator itself is in C, but that's shared between all targets.

Paul




Re: [Qemu-devel] Using Microsoft-provided Windows images

2007-08-01 Thread GUERRAZ Francois
Hello.

Micro$oft's 64bits OSes are known to be problematic w/ kvm.

I guess that the main problem w/ Qemu is that Microsoft Virtual Server
can emulate a SCSI controller and Qemu cannot... I havent checked but I
bet they installed their VM's with just SCSI drivers...
Try to install IDE drivers from VM Ware and then to boot from QEMU.
Also, try to disable ACPI (update the computer driver to Standard PC
if available)

Regards,

François.

Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit :
 I have been playing around with the demonstration Windows images
 downloadable from Microsoft just to see how hard it would be to use the
 OSs they provide. The images are designed for Microsoft Virtual Server,
 but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU
 won't boot the images (not a difficult problem, I think) but VMware can.
 I'll try other free virtualisation systems at some point.
 
 See http://shearer.org/Microsoft_Demo_VMs for my notes so far.
 





Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)

2007-08-01 Thread Dan Shearer
On Wed, Aug 01, 2007 at 03:23:45PM +0100, Paul Brook wrote:

 Some parts of this code effectively are a special language for
 describing a CPU, that happen to be implemented using the C
 preprocessor :-)

Right, in the same way that QEMU devices written in C are in a device
language? :-)

-- 
Dan Shearer
[EMAIL PROTECTED]




[Qemu-devel] Patch: let qemu work with latest bochsbios

2007-08-01 Thread Bernhard Kauer
The boot_device is not communicated to the bochsbios
through the CMOS. The following patch allows to boot 
via network on the newest bochsbios.


Bernhard Kauer




[Qemu-devel] Patch: let qemu work with latest bochsbios

2007-08-01 Thread Bernhard Kauer
The boot_device is not communicated to the bochsbios
through the CMOS. The following patch allows to boot 
via network on the newest bochsbios.


Bernhard Kauer
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.323
diff -u -r1.323 vl.c
--- vl.c	29 Jul 2007 17:57:25 -	1.323
+++ vl.c	1 Aug 2007 15:36:31 -
@@ -7828,7 +7828,7 @@
 	fprintf(stderr, No valid PXE rom found for network device\n);
 	exit(1);
 	}
-	boot_device = 'c'; /* to prevent confusion by the BIOS */
+	//boot_device = 'c'; /* to prevent confusion by the BIOS */
 }
 #endif
 
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.81
diff -u -r1.81 pc.c
--- hw/pc.c	6 Jun 2007 16:26:13 -	1.81
+++ hw/pc.c	1 Aug 2007 15:36:31 -
@@ -197,6 +197,9 @@
 case 'd':
 rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
 break;
+case 'n':
+rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
+break;	
 }
 
 /* floppy type */


Re: [Qemu-devel] Patch: let qemu work with latest bochsbios

2007-08-01 Thread Anthony Liguori

Bernhard Kauer wrote:

The boot_device is not communicated to the bochsbios
through the CMOS. The following patch allows to boot 
via network on the newest bochsbios.



Bernhard Kauer
  



Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.323
diff -u -r1.323 vl.c
--- vl.c29 Jul 2007 17:57:25 -  1.323
+++ vl.c1 Aug 2007 15:36:31 -
@@ -7828,7 +7828,7 @@
fprintf(stderr, No valid PXE rom found for network device\n);
exit(1);
}
-   boot_device = 'c'; /* to prevent confusion by the BIOS */
+   //boot_device = 'c'; /* to prevent confusion by the BIOS */
 }
  


Please don't comment out code.  Just delete it.

Regards,

Anthony Liguori


 #endif
 
Index: hw/pc.c

===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.81
diff -u -r1.81 pc.c
--- hw/pc.c 6 Jun 2007 16:26:13 -   1.81
+++ hw/pc.c 1 Aug 2007 15:36:31 -
@@ -197,6 +197,9 @@
 case 'd':
 rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
 break;
+case 'n':
+rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
+break; 
 }
 
 /* floppy type */
  






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

2007-08-01 Thread Daniel P. Berrange
On Tue, Jul 31, 2007 at 08:46:49PM -0500, Anthony Liguori wrote:
 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.

Ok I'll add a separate command for that - any preference for naming.
I thought about 'change vncpassword', but the 'change' command requires
2 args and we'd only have 1 here.  Or if we think there may be other
devices/drivers which will have passwords in the future we could have
'change password vnc' as the command. 

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

Good point. I'll add support for that.

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




Re: [Qemu-devel] Using Microsoft-provided Windows images

2007-08-01 Thread risc
on x86, qemu by default does not emulate a scsi device.

if you look at my last set of postings, you will see a patch set for adding 
scsi controllers on demand.

its got some code formatting issues, so i understand why it hasnt been merged 
as of yet. i intend to publish a new version in the next couple of days.

Julia Longtin [EMAIL PROTECTED]

On Wed, Aug 01, 2007 at 04:33:31PM +0200, GUERRAZ Francois wrote:
 Hello.
 
 Micro$oft's 64bits OSes are known to be problematic w/ kvm.
 
 I guess that the main problem w/ Qemu is that Microsoft Virtual Server
 can emulate a SCSI controller and Qemu cannot... I havent checked but I
 bet they installed their VM's with just SCSI drivers...
 Try to install IDE drivers from VM Ware and then to boot from QEMU.
 Also, try to disable ACPI (update the computer driver to Standard PC
 if available)
 
 Regards,
 
 François.
 
 Le mercredi 01 août 2007 à 23:35 +0930, Dan Shearer a écrit :
  I have been playing around with the demonstration Windows images
  downloadable from Microsoft just to see how hard it would be to use the
  OSs they provide. The images are designed for Microsoft Virtual Server,
  but can be successfully converted to qcow2 and vhdx using qemu-img. QEMU
  won't boot the images (not a difficult problem, I think) but VMware can.
  I'll try other free virtualisation systems at some point.
  
  See http://shearer.org/Microsoft_Demo_VMs for my notes so far.
  
 
 
 




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

2007-08-01 Thread Daniel P. Berrange
On Tue, Jul 31, 2007 at 08:50:29PM -0500, Anthony Liguori wrote:
 Daniel P. Berrange wrote:
 @@ -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?

Sure I can make that change - I wasn't sure what people's preference for
this was so I took conservative approach of not enabling it unless it
is explicitly asked for. Happy to change it to enable by default if the
pkg-config probing succeeds, and allow a configure arg to explicitly
disable it.

 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.

Sorry, this chunk wasn't supposed to be included - I'll submit it as 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

Ok.


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




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

2007-08-01 Thread Daniel P. Berrange
On Tue, Jul 31, 2007 at 08:54:09PM -0500, Anthony Liguori wrote:
 Daniel P. Berrange wrote:
 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.
   
 
 It concerns me a little to add 4 new command line options.  Perhaps just 
 supply a directory and hard code the names of each file?  Then it could 
 even be specified as -vnc 
 [proto]:proto-arg[,tls[,x509[:/path/to/x509/certs]]]  with a 
 reasonable default provided.

Including it as part of the main vnc arg would be nice as it'd let the admin
set/change it from the monitor too. Merely specifying a directory would be
fine with me - its trivial to symlink files if the admin wants to store them
in some other way.

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




Re: [Qemu-devel] [PATCH] make /usr/bin/qemu the native arch

2007-08-01 Thread Robert Millan
 Management tools for QEMU will have come to rely on existing semantics
 of /usr/bin/qemu being i386.

How about just deprecating it?  For example, we could make
/usr/bin/qemu  be a script with:

#!/bin/bash
echo warning: $0 is deprecated, use qemu-system-i386 instead
exec qemu-system-i386 $@

 Changing this for merely cosmetic reasons [...]

It's not just cosmetic.  I recall you sent me some benchmarks (too bad
they didn't make it to the list, and I somehow lost that mail), but
they were done on i386 (which remains unaffected).  On x86_64, results
are different (specially if you have setup kqemu which only works with
qemu-system-x86_64).

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.




Re: [Qemu-devel] IBM makes AIX 6 beta available for download for everyone

2007-08-01 Thread Blue Swirl
The correct place for these questions would be the OpenBIOS list
(blatantly cross-posted).

On 7/30/07, Andreas Färber [EMAIL PROTECTED] wrote:

 Am 19.07.2007 um 09:23 schrieb Natalia Portillo:

  El jue, 19-07-2007 a las 00:46 +0200, Andreas Färber escribió:
  Am 18.07.2007 um 18:26 schrieb Blue Swirl:
 
  It looks like open hack'ware is pretty much stalled, so its hard
  telling
  what progress will be made futurewise.
 
  Might it be possible to replace it with OpenBIOS?
 
  Sure, and as both are GPL useful, code can be shared. But some PPC
  developers are needed. It may still be easier to fix the OHW bugs
  than
  start over anew.
 
  Not sure I understand... I thought Open Firmware was based on
  platform independent Forth code?
  I'm running on ppc64 and could try to compile something under Linux
  in case that's the problem.
  Yes, OF is basically a Forth-interpreter.
  Of course this Forth-interpreter is in C and compile to machine
  code :p

 Yes, that is obvious. Not so obvious was what ppc *developers* were
 needed for.
 I got the other answer afterwards saying that HFS etc. support needed
 to be added.


  Try to compile OpenBIOS under Linux/PPC (using 32bit compiler, not
  ppc64) and comment us.

 I tried SVN HEAD of both fcode-utils and openbios-devel.

 OpenBIOS supposedly has support for ppc and cross-ppc archs but that
 is not true. It currently only has support for cross-ppc (for the old
 PearPC emulator it seems). I copied these files as ppc_config.xml and
 ppc_rules.xml respectively to get the ppc target, in ppc_rules.xml
 changed the tool names to use the standard gcc etc. and was able to
 compile okay. Products based on this unmodified configuration were
 among others an openbios-pearpc.elf file - I thus changed ppc_rom.bin
 in some ppc files to this filename. Launching qemu-system-sparc -boot
 d -cdrom /dev/cdrom with a Debian Etch DVD inserted resulted in an
 opcode error. My guess thus is that this OpenBIOS file is not suited
 for qemu in that configuration?

 Some observations that might be of interest:
 - OpenBIOS has support for some (not all) PowerPC processors
 according to some Readme
 - it specifically mentions ppc/AIX and has some apparent IBM
 contributions despite the missing ppc target
 - the cross-ppc config mentions HFS and HFSP which I guess refer to
 HFS and HFS+ filesystems respectively (HFS was set to false, HFSP to
 true)

 Maybe someone can shed some more light on what exactly needs to be
 changed config-wise or is missing in OpenBIOS or qemu in order to
 boot AIX 6 or any Linux.

 Andreas




[Qemu-devel] QEMU - windows Vista

2007-08-01 Thread Augusto Pedroza
Hi guys,
  I have had success using qemu + LinuxBIOS + ADLO to boot win2k and winXP
but with windows vista I have no idea what the problems are.
I have tried  to use qemu with its normal  bochs bios   to boot VISTA
installation DVD. I get the initial loading screen followed by a black
screen ans that's it.
Could you guys show me any thread or tell me if anybody has detected the
problem with windows Vista?

Thanks a lot,
-- 
Augusto Pedroza


[Qemu-devel] vnc improvement/bugfix patches from xen

2007-08-01 Thread Matthew Kent
After some issues with qemu vnc I happened upon the patches xen carries
in xen-unstable.hg/tools/ioemu/patches/. After getting them to apply
cleanly they have vastly improved my experience with vnc.

I've taken these, omitted any that are xen specific or add extra
features to qemu, and made some patches that apply cleanly to the latest
qemu and kvm-33 sources. 

http://magoazul.com/proj/qemu/from_xen-unstable.hg_7c5c3aa858cc/

They seem to resolve the following issues for me:

- having the vncviewer 4.1.2 die with:
Rect too big: 4260x16389 at 4259,4323 exceeds 720x400
Aborted
- having some odd stuck bits on the display when using the mouse via gdm
or vim
 - fixed by vnc-backoff-screen-scan/vnc-cleanup/vnc-fixes

- occasionally having the vnc server go into an infinite loop thus
screwing up the entire vm (verified with gdb)
 - fixed by vnc-protocol-fixes

- keypad not working
 - fixed by vnc-keypad-handling

[vnc-altgr-keysym/vnc-fix-text-display-shift-key not sure, included em
anyway]

Obviously I had *zero* hand in creating these patches and the original
authors deserve the credit, I'm merely providing them for anyone
experiencing the same issues. What I have done though is abused the
patched qemu and kvm installs pretty thoroughly with vnc over the past
week without issue.

Also, in the course of this I read the recent 'Merging QEMU-DM upstream'
slides from XenSummit by Anthony Liguori who I've seen on this list.
Wondering if this is ongoing and I just duplicated some work that's
already done? :)
-- 
Matthew Kent [EMAIL PROTECTED]
http://magoazul.com