Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' cast... Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 01:19:56 Modified files: hw : mips_r4k.c target-mips: cpu.h exec.h fop_template.c helper.c mips-defs.h op.c op_helper.c op_helper_mem.c op_mem.c op_template.c translate.c Log message: Preliminiary MIPS64 support, disabled by default due to performance impact. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.24r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/fop_template.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper_mem.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_mem.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_template.c?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.28r2=1.29 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
Fabrice Bellard wrote: You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' cast... Then it may not work. A MIPS64 CPU requires properly sign-extended 32bit values. Host architectures can define either sign- or zero- Extension for 32bit values in 64bit Registers. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 13:48:28 Modified files: hw : mips_r4k.c target-mips: cpu.h helper.c op.c op_helper.c translate.c Log message: Scrap SIGN_EXTEND32. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.20r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.29r2=1.30 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
On 12/21/06, Thiemo Seufer [EMAIL PROTECTED] wrote: Fabrice Bellard wrote: You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' cast... Then it may not work. A MIPS64 CPU requires properly sign-extended 32bit values. Host architectures can define either sign- or zero- Extension for 32bit values in 64bit Registers. Whether or not it works, GCC *WILL* optimize it away as a redundant statement, if it deems so (i.e., if it's called with some flag that enables cse/gcse and peephole optimizations, and the variable(s) in question is(are) not declared volatile). IMHO macros like these SHOULD stay, as they are mostly innocuous and happen to document the target machine behaviour. Cheers, A. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Simplily linux-user/path.c
On Tuesday 12 December 2006 12:56, Kirill Shutemov wrote: I have no ideas why path.c is so complex. Any? In the attachment rewritten version. It has tested with qemu-arm. Your patch is buggy. You're returning a pointer to a stack allocated object. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu hw/mips_r4k.c target-mips/cpu.h target-mip...
André Braga wrote: On 12/21/06, Thiemo Seufer [EMAIL PROTECTED] wrote: Fabrice Bellard wrote: You should suppress the SIGN_EXTEND32() macro and just use an 'int32_t' cast... Then it may not work. A MIPS64 CPU requires properly sign-extended 32bit values. Host architectures can define either sign- or zero- Extension for 32bit values in 64bit Registers. Whether or not it works, GCC *WILL* optimize it away as a redundant statement, Only iff it is redundant, which is what we want to achieve. if it deems so (i.e., if it's called with some flag that enables cse/gcse and peephole optimizations, and the variable(s) in question is(are) not declared volatile). Currently it appears to work as is. Given that the CPU env is a global it is unlikely gcc can use fancy optimizations. When compiling with -combine we may need to declare the emulated machine registers volatile. IMHO macros like these SHOULD stay, as they are mostly innocuous and happen to document the target machine behaviour. I disagree, it clutters the source more, and a cast provides the same information. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu dyngen.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 16:49:27 Modified files: . : dyngen.c Log message: Fix compiler warnings, add signed versions of some swab functions. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.46r2=1.47 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vnchextile.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 16:50:09 Modified files: . : vnchextile.h Log message: Silence a spurious gcc warning. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vnchextile.h?cvsroot=qemur1=1.2r2=1.3 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QEMU x86_64: bug with floats (with test program)
Hi !
I've found a bug in Qemu: conversion of floats to strings fails
in some cases. For example, Ganglia (cluster monitoring software), shows
random values and as well as PHP5 programs.
Compile this and link with libapr-1:
==test.c===
#include stdio.h
#include math.h
#include apr.h
#include apr_strings.h
void main(void)
{
char buf[60];
double d = M_PI;
snprintf(buf, 60, %f\n, d);
printf(buf);
apr_snprintf(buf, 60, %f\n, d);
printf(buf);
}
Under a SLES 10/64 bits, you'll see something like:
3.141593
3.Ojuç_
I tested with Qemu 0.8.2 and the CVS, and of course, it works on a real
system (a Dell PE1950).
So it's a QEMU bug. Is it triggered by weird code produced by gcc 4.1.0 ? Or a
FPU emulation bug ? Any ideas ?
--
Ludovic DROLEZ Linbox / FreeALter Soft
http://lrs.linbox.org
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw smc91c111.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 17:23:49 Modified files: hw : smc91c111.c Log message: Avoid unused variable compiler warning. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/smc91c111.c?cvsroot=qemur1=1.4r2=1.5 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw tcx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 17:24:45 Modified files: hw : tcx.c Log message: Don't cast lvalues, fixes compiler warning. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemur1=1.9r2=1.10 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix some configure/Makefile weirdness
Hello All, the appended patch allows for propagating CFLAGS and LDFLAGS to the host Makefile. This reactivates the (undocumented) --extra-cflags= and --extra-ldflags= options of configure which are currently NOPs. It also removes the CFLAGS=-O2 default from configure since it is already hardcoded in Makefile and Makefile.target. Comments? Thiemo Index: Makefile === RCS file: /sources/qemu/qemu/Makefile,v retrieving revision 1.106 diff -u -p -r1.106 Makefile --- Makefile5 Aug 2006 21:29:27 - 1.106 +++ Makefile21 Dec 2006 18:48:34 - @@ -5,14 +5,14 @@ include config-host.mak .PHONY: all clean distclean dvi info install install-doc tar tarbin \ speed test test2 html dvi info -CFLAGS=-Wall -O2 -g -fno-strict-aliasing -I. +CFLAGS+=-Wall -O2 -g -fno-strict-aliasing -I. ifdef CONFIG_DARWIN CFLAGS+= -mdynamic-no-pic endif ifeq ($(ARCH),sparc) CFLAGS+=-mcpu=ultrasparc endif -LDFLAGS=-g +LDFLAGS+=-g LIBS= DEFINES+=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE TOOLS=qemu-img$(EXESUF) Index: configure === RCS file: /sources/qemu/qemu/configure,v retrieving revision 1.113 diff -u -p -r1.113 configure --- configure 19 Dec 2006 03:31:34 - 1.113 +++ configure 21 Dec 2006 18:48:34 - @@ -243,11 +243,6 @@ for opt do esac done -# Checking for CFLAGS -if test -z $CFLAGS; then -CFLAGS=-O2 -fi - if test x$show_help = xyes ; then cat EOF ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/slirp tcp.h tcp_subr.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 19:10:59 Modified files: slirp : tcp.h tcp_subr.c Log message: Enable TCP_NODELAY, by Daniel Jacobowitz. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/tcp.h?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/tcp_subr.c?cvsroot=qemur1=1.6r2=1.7 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu block-raw.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 19:14:11 Modified files: . : block-raw.c Log message: Fix inaccessible boot device on FreeBSD, by Juergen Lock. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemur1=1.10r2=1.11 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi qemu_socket.h vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/21 19:46:43 Modified files: . : qemu-doc.texi qemu_socket.h vl.c Log message: Run monitor over unix domain sockets, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.113r2=1.114 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu_socket.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.219r2=1.220 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/slirp tcp.h tcp_subr.c
Hi, it might be better to use a system include file (netinet/tcp.h for Linux, winsock2.h for Windows) for the declaration of TCP_NODELAY instead of a definition in tcp.h. Regards Stefan Thiemo Seufer schrieb: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 06/12/21 19:10:59 Modified files: slirp : tcp.h tcp_subr.c Log message: Enable TCP_NODELAY, by Daniel Jacobowitz. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/tcp.h?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/tcp_subr.c?cvsroot=qemur1=1.6r2=1.7 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: qemu/rtl8139: Max transmit frame size
On 11/17/06, Herbert Xu [EMAIL PROTECTED] wrote: On Wed, Nov 15, 2006 at 03:38:27PM +1100, herbert wrote: CP_TX_BUFFER_SIZE is already 64K. So it seems to me that we don't need the while loop to extend the buffer at all since no transmitted packet should be anywhere near this size. Are there any objections to getting rid of the following while loop altogether and replacing it with a straight failure? Since I haven't heard any objections, here is a patch to do just that. [QEMU] rtl8139: Disallow chaining above 64K As it stands the 8139C+ TX chaining is only bounded by realloc failure. This is contrary to how the real hardware operates. It also has DoS potential when ioemu runs in dom0. This patch makes any attempt to chain a frame beyond 64K fail immediately. True, a limit would be useful. It may be possible to start a chain at first TX descriptor and keep feeding the card with new buffers while hardware is sending older ones, without underrun, if checksum offloading is disabled. Emulation is assembling a complete packet to feed slirp routine - so there is another limit on packet size, the one slirp is able to handle. It would be nice to know what is the actual hardware limit for chaining. Only reference to 64K I found in docs is referring to receive ring buffer size in C mode. -- Kind Regards, Igor V. Kovalenko ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/slirp tcp.h tcp_subr.c
Stefan Weil wrote: Hi, it might be better to use a system include file (netinet/tcp.h for Linux, winsock2.h for Windows) for the declaration of TCP_NODELAY instead of a definition in tcp.h. I don't know if TCP/IP is required to use the same numeric value across implementations, so I stay with the slirp header for slirp use. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi vl.c vl.h vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/22 02:09:07 Modified files: . : qemu-doc.texi vl.c vl.h vnc.c Log message: Unix domain socket support for VNC, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.114r2=1.115 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.220r2=1.221 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.156r2=1.157 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.9r2=1.10 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/22 02:11:31 Modified files: . : qemu-doc.texi vl.c Log message: Daemonize option, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.115r2=1.116 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.221r2=1.222 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw ide.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 06/12/22 02:14:50 Modified files: hw : ide.c Log message: Fix CDROM change, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemur1=1.48r2=1.49 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Question/problems with Qemu and 64Bit Opensuse 10.2
Just forgot to give the info about my system: Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also, while compiling Qemu I got quite some warning about casting pointers to integer of different size (64bit vs 32 bit). Is this ok? Regards, Werner Werner Dittmann wrote: All, currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. Using a plain 0.82 didn't work out, after the Install screen Qemu goes in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). I could not even stop Qemu but had to use kill -9 . Because of some mail in the list that reported similar errors I downloaded the latest CVS version and built it using a gcc 3.3. That didn't solve the problem: It seems to be in a loop but I can close the qemu window and the window also grabs the mouse cursor (that was not the case with the 0.8.2 version). After loading the kernel I get the following message on the console (only in VESA mode): Decompressing Linux ... done. Booting the kernel. and at the bottom of the console screen the message (without the qutes): kernel direct mapping tables up to 1 @ 8000-d000 I tried to switch on some -d but I don't know which one is relevant here. I tried -d int but this produced about 90MB log data in just some seconds. Which info do you need to get down to the problem? What can I try to tackle the problem? Regards, Werner PS: Because I'm somewhat experienced with security software I would ask if there is any interest to have a TPM module (Software based TPM) for Qemu that looks like a real HW TPM according the the TPM specs? If yes I would start to look how to do it for Qemu. There is a software based TPM avaliable with a GPL licence. The only thing to do would be to wrap it with the HW interface functions (it's a memory mapped interface) so that standard drivers would see it as standard TPM module. Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
