[Qemu-devel] [PATCH] softfloat missing functions
Some functions are missing from the softfloat API. Those are:
float32 uint32_to_float32( unsigned int STATUS_PARAM);
float64 uint64_to_float64( uint64_t v STATUS_PARAM);
unsigned int float32_to_uint32( float32 a STATUS_PARAM);
unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM);
unsigned int float64_to_uint32( float64 STATUS_PARAM );
unsigned int float64_to_uint32_round_to_zero( float64 STATUS_PARAM );
uint64_t float64_to_uint64( float64 STATUS_PARAM );
uint64_t float64_to_uint64_round_to_zero( float64 STATUS_PARAM );
As I need those function to emulate some PowerPC operations, here's a
proposal for their implementation.
Note that float64_to_uint64 functions are not correct, as they won't
return results between INT64_MAX and UINT64_MAX. Hope someone may know
the proper solution for this.
Please comment and help me fix this.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: fpu/softfloat-native.c
===
RCS file: /sources/qemu/qemu/fpu/softfloat-native.c,v
retrieving revision 1.6
diff -u -d -d -p -r1.6 softfloat-native.c
--- fpu/softfloat-native.c 28 Oct 2006 19:27:11 - 1.6
+++ fpu/softfloat-native.c 19 Mar 2007 07:30:45 -
@@ -59,6 +59,11 @@ float32 int32_to_float32(int v STATUS_PA
return (float32)v;
}
+float32 uint32_to_float32(unsigned int v STATUS_PARAM)
+{
+return (float32)v;
+}
+
float64 int32_to_float64(int v STATUS_PARAM)
{
return (float64)v;
@@ -78,6 +83,10 @@ float64 int64_to_float64( int64_t v STAT
{
return (float64)v;
}
+float64 uint64_to_float64( uint64_t v STATUS_PARAM)
+{
+return (float64)v;
+}
#ifdef FLOATX80
floatx80 int64_to_floatx80( int64_t v STATUS_PARAM)
{
@@ -132,6 +141,37 @@ floatx80 float32_to_floatx80( float32 a
}
#endif
+unsigned int float32_to_uint32( float32 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = llrintf(a);
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = (int64_t)a;
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+
/*
| Software IEC/IEEE single-precision operations.
**/
@@ -218,6 +258,63 @@ float128 float64_to_float128( float64 a
}
#endif
+unsigned int float64_to_uint32( float64 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = llrint(a);
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = (int64_t)a;
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
+{
+uint64_t res;
+int64_t v;
+
+v = llrint(a);
+if (v 0) {
+res = 0;
+} else {
+res = v;
+}
+return res;
+}
+uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
+{
+uint64_t res;
+int64_t v;
+
+v = (int64_t)a;
+if (v 0) {
+res = 0;
+} else {
+res = v;
+}
+return res;
+}
+
/*
| Software IEC/IEEE double-precision operations.
**/
Index: fpu/softfloat-native.h
===
RCS file: /sources/qemu/qemu/fpu/softfloat-native.h,v
retrieving revision 1.8
diff -u -d -d -p -r1.8 softfloat-native.h
--- fpu/softfloat-native.h 28 Oct 2006 19:27:11 - 1.8
+++ fpu/softfloat-native.h 19 Mar 2007 07:30:45 -
@@ -99,6 +99,7 @@ void set_floatx80_rounding_precision(int
| Software IEC/IEEE integer-to-floating-point conversion routines.
**/
float32 int32_to_float32( int STATUS_PARAM);
+float32 uint32_to_float32( unsigned int STATUS_PARAM);
float64 int32_to_float64( int STATUS_PARAM);
#ifdef FLOATX80
floatx80 int32_to_floatx80( int STATUS_PARAM);
@@ -108,6 +109,7 @@ float128 int32_to_float128( int STATUS_P
#endif
float32 int64_to_float32( int64_t STATUS_PARAM);
float64 int64_to_float64( int64_t STATUS_PARAM);
+float64 uint64_to_float64( uint64_t v STATUS_PARAM);
#ifdef FLOATX80
floatx80 int64_to_floatx80( int64_t STATUS_PARAM);
#endif
@@ -120,6 +122,8 @@ float128 int64_to_float128( int64_t STAT
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/03/19 08:08:28 Modified files: linux-user : main.c Log message: Add -cpu option for linux user emulation. Only usable for PowerPC and ARM for now. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.102r2=1.103 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
Hi there, On 17.03.2007, at 20:30, Philip Boulain wrote: Hi! I'll keep this succinct, because I'm sure they'd be FAQ-grade questions if this list had a FAQ: :) 1) Where's the version repository for KQEMU? It doesn't appear to be under/alongside QEMU itself. 2) Has anyone made any progress with porting KQEMU to Darwin x86? I've had a look at the GPL release (hurrah) and it looked to me like the platform-specific parts would mostly involve writing an I/ O Kit Device Driver which provided a device node with suitable ioctl support[1], as the FreeBSD version does. The mailing list archives show some activity in this area, but without 1) it's hard to get an overview. (There are also obvious-looking compilation problems with the distributed 1.3.0pre11 sources, but I'm guessing that someone who knows assembler better than now has fixed them by now.) I have made a empty kext and a dummy client to do some tests on this topics. Boundary crossing is working well, so by now the kext part is ready. http://www.kronenberg.org/files/kqemu_poc.zip Unfortunately, Apple decided to remove/hide some of the vm_* API (especially vm_map_(un)wire in Tiger. (It was available on Panther. vm_map_user_pageable was never part of Darwin). So any suggestions on how to lock user pages in Darwin would be very welcome. So right now, I'm reading thru lots of stuff to replace the unsupported kqemu-freebsd.c function calls. If someone is interested, I post snapshots or put it in the http://www.kju-app.org repository, until it's working and can be merged. Thanks, LionsPhil 1. http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/boundaries/chapter_14_section_6.html Best Regards Mike ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] please review this scsi patch
Wang Cheng Yeh wrote: thanks If you include a description of what the patch does and why it is necessary, it will probably be reviewed a lot quicker. -- error compiling committee.c: too many arguments to function ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/linux-user syscall.c
On [Sat, 17.03.2007 01:27], Paul Brook wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Paul Brook pbrook 07/03/17 01:27:24 Modified files: linux-user : syscall.c Log message: Usermode recv syscall fix. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.89r2=1.90 Can you review other trivial bug fixes? [PATCH] fcntl64 fix [BUG] [PATCH] Syscall gethostname fix And new syscall implementation: [PATCH] Syscall clock_gettime and clock_getres implementaion signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 12:16:29 Modified files: linux-user : main.c Log message: Support -cpu selection for mips usermode emulation. Fix segfault when dispaying the -cpu list help. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.103r2=1.104 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 12:22:40 Modified files: . : configure Log message: Solaris needs -lrt, spotted by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.131r2=1.132 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] please review this scsi patch
Avi Kivity [EMAIL PROTECTED] wrote: Wang Cheng Yeh wrote: thanks If you include a description of what the patch does and why it is necessary, it will probably be reviewed a lot quicker. He's posted this one before, and the patch fixes such blatent programming errors like an XOR case option using | instead of ^ and a 32-bit write split into 4 byte writes, and passing the third byte twice. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] scsi patch
? wrote: --- ../../tmp/qemu-0.9.0/hw/lsi53c895a.c2007-02-06 07:01: 54.0 +0800 +++ lsi53c895a.c2007-03-08 20:50:03.094098835 +0800 @@ -251,7 +251,7 @@ uint32_t ia; uint32_t sbc; uint32_t csbc; -uint32_t scratch[13]; /* SCRATCHA-SCRATCHR */ +uint32_t scratch[18]; /* SCRATCHA-SCRATCHR */ This still looks inconsistent. SCRATCHR suggests 18 available registers, but the code below handles only 17 scratch registers. Could you check what's the right thing there? Otherwise the patch looks good. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 13:05:13 Modified files: linux-user : syscall.c Log message: Fix allocation sizes in getpeername/getsockname, spotted by Kirill A. Shutemov. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.90r2=1.91 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 13:09:22 Modified files: linux-user : syscall.c Log message: Add missing header includes. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.91r2=1.92 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: arm, mips and sparc targets on Host Solaris/sparc
This patch is to fix (correctly) running mips, sparc and arm targets on a Solaris/Sparc host. This patch reverts the patch posted February 2nd, 2007, (found at http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg8.html for reference). Juergen Keil found that config.h was not included in target-arm/exec.h and config.h was included *after* dyngen-exec.h in target-sparc/exec.h. By config.h not being included before dyngen-exec.h, the code in dyngen-exec.h assumed a linux-sparc host and used different register allocations which were incompatible with Solaris/Sparc. I can boot the sparc-test and mips-tests now. The arm-test is not functional due a Solaris library bug, and we are working on a fix. Bendiff -ruN qemu-ORIG/target-arm/exec.h qemu/target-arm/exec.h --- qemu-ORIG/target-arm/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-arm/exec.h 2007-03-19 09:19:44.33096 -0400 @@ -17,19 +17,13 @@ * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include config.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUARMState *env; -uint32_t T0; -uint32_t T1; -uint32_t T2; -#else register struct CPUARMState *env asm(AREG0); register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); register uint32_t T2 asm(AREG3); -#endif /* TODO: Put these in FP regs on targets that have such things. */ /* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */ diff -ruN qemu-ORIG/target-mips/exec.h qemu/target-mips/exec.h --- qemu-ORIG/target-mips/exec.h 2007-02-28 17:37:42.0 -0500 +++ qemu/target-mips/exec.h 2007-03-19 09:20:30.439432000 -0400 @@ -7,11 +7,7 @@ #include mips-defs.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUMIPSState *env; -#else register struct CPUMIPSState *env asm(AREG0); -#endif #if defined (USE_64BITS_REGS) typedef int64_t host_int_t; @@ -21,11 +17,6 @@ typedef uint32_t host_uint_t; #endif -#if defined(__sparc__) -host_uint_t T0; -host_uint_t T1; -host_uint_t T2; -#else #if TARGET_LONG_BITS HOST_LONG_BITS #define T0 (env-t0) #define T1 (env-t1) @@ -35,7 +26,6 @@ register host_uint_t T1 asm(AREG2); register host_uint_t T2 asm(AREG3); #endif -#endif #if defined (USE_HOST_FLOAT_REGS) #error implement me. diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h 2007-03-19 09:22:48.76391 -0400 @@ -3,11 +3,7 @@ #include dyngen-exec.h #include config.h -#if defined(__sparc__) -struct CPUSPARCState *env; -#else register struct CPUSPARCState *env asm(AREG0); -#endif #ifdef TARGET_SPARC64 #define T0 (env-t0) @@ -15,13 +11,8 @@ #define T2 (env-t2) #define REGWPTR env-regwptr #else -#if defined(__sparc__) -register uint32_t T0 asm(AREG3); -register uint32_t T1 asm(AREG2); -#else register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); -#endif #undef REG_REGWPTR // Broken #ifdef REG_REGWPTR @@ -33,11 +24,7 @@ #define reg_REGWPTR #ifdef AREG4 -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG4); -#endif #define reg_T2 #else #define T2 (env-t2) @@ -45,14 +32,10 @@ #else #define REGWPTR env-regwptr -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG3); #endif #define reg_T2 #endif -#endif #define FT0 (env-ft0) #define FT1 (env-ft1) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Makefile.target linux-user/syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 13:32:45 Modified files: . : Makefile.target linux-user : syscall.c Log message: Linux usermode clock_gettime/clock_getres emulation, by Kirill A. Shutemov. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.150r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.92r2=1.93 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/darwin-user syscall.c syscalls.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 13:43:05 Modified files: darwin-user: syscall.c syscalls.h Log message: Handling more darwin-user syscalls, by Ilya Shar. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/syscall.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/syscalls.h?cvsroot=qemur1=1.2r2=1.3 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: arm, mips and sparc targets on Host Solaris/sparc
Ben Taylor wrote: This patch is to fix (correctly) running mips, sparc and arm targets on a Solaris/Sparc host. This patch reverts the patch posted February 2nd, 2007, (found at http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg8.html for reference). Juergen Keil found that config.h was not included in target-arm/exec.h and config.h was included *after* dyngen-exec.h in target-sparc/exec.h. [snip] diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h 2007-03-19 09:22:48.76391 -0400 @@ -3,11 +3,7 @@ #include dyngen-exec.h #include config.h You missed a bit... Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: arm, mips and sparc targets on Host Solaris/sparc
Thiemo Seufer [EMAIL PROTECTED] wrote: Ben Taylor wrote: This patch is to fix (correctly) running mips, sparc and arm targets on a Solaris/Sparc host. This patch reverts the patch posted February 2nd, 2007, (found at http://lists.gnu.org/archive/html/qemu-devel/2007-02/msg8.html for reference). Juergen Keil found that config.h was not included in target-arm/exec.h and config.h was included *after* dyngen-exec.h in target-sparc/exec.h. [snip] diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h2007-03-19 09:22:48.76391 -0400 @@ -3,11 +3,7 @@ #include dyngen-exec.h #include config.h You missed a bit... sigh Thanks for the catch. Here's the updated patch Bendiff -ruN qemu-ORIG/target-arm/exec.h qemu/target-arm/exec.h --- qemu-ORIG/target-arm/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-arm/exec.h 2007-03-19 09:19:44.33096 -0400 @@ -17,19 +17,13 @@ * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include config.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUARMState *env; -uint32_t T0; -uint32_t T1; -uint32_t T2; -#else register struct CPUARMState *env asm(AREG0); register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); register uint32_t T2 asm(AREG3); -#endif /* TODO: Put these in FP regs on targets that have such things. */ /* It is ok for FT0s and FT0d to overlap. Likewise FT1s and FT1d. */ diff -ruN qemu-ORIG/target-mips/exec.h qemu/target-mips/exec.h --- qemu-ORIG/target-mips/exec.h 2007-02-28 17:37:42.0 -0500 +++ qemu/target-mips/exec.h 2007-03-19 09:20:30.439432000 -0400 @@ -7,11 +7,7 @@ #include mips-defs.h #include dyngen-exec.h -#if defined(__sparc__) -struct CPUMIPSState *env; -#else register struct CPUMIPSState *env asm(AREG0); -#endif #if defined (USE_64BITS_REGS) typedef int64_t host_int_t; @@ -21,11 +17,6 @@ typedef uint32_t host_uint_t; #endif -#if defined(__sparc__) -host_uint_t T0; -host_uint_t T1; -host_uint_t T2; -#else #if TARGET_LONG_BITS HOST_LONG_BITS #define T0 (env-t0) #define T1 (env-t1) @@ -35,7 +26,6 @@ register host_uint_t T1 asm(AREG2); register host_uint_t T2 asm(AREG3); #endif -#endif #if defined (USE_HOST_FLOAT_REGS) #error implement me. diff -ruN qemu-ORIG/target-sparc/exec.h qemu/target-sparc/exec.h --- qemu-ORIG/target-sparc/exec.h 2007-02-01 20:03:34.0 -0500 +++ qemu/target-sparc/exec.h 2007-03-19 09:57:13.694272000 -0400 @@ -1,13 +1,9 @@ #ifndef EXEC_SPARC_H #define EXEC_SPARC_H 1 -#include dyngen-exec.h #include config.h +#include dyngen-exec.h -#if defined(__sparc__) -struct CPUSPARCState *env; -#else register struct CPUSPARCState *env asm(AREG0); -#endif #ifdef TARGET_SPARC64 #define T0 (env-t0) @@ -15,13 +11,8 @@ #define T2 (env-t2) #define REGWPTR env-regwptr #else -#if defined(__sparc__) -register uint32_t T0 asm(AREG3); -register uint32_t T1 asm(AREG2); -#else register uint32_t T0 asm(AREG1); register uint32_t T1 asm(AREG2); -#endif #undef REG_REGWPTR // Broken #ifdef REG_REGWPTR @@ -33,11 +24,7 @@ #define reg_REGWPTR #ifdef AREG4 -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG4); -#endif #define reg_T2 #else #define T2 (env-t2) @@ -45,14 +32,10 @@ #else #define REGWPTR env-regwptr -#if defined(__sparc__) -register uint32_t T2 asm(AREG0); -#else register uint32_t T2 asm(AREG3); #endif #define reg_T2 #endif -#endif #define FT0 (env-ft0) #define FT1 (env-ft1) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH Makefile.target cleanup
This patch cleans up Makefile target for sparc32 and sparc64 Solaris and non-Solaris targets share a large amount of the definitions, so I split out the common parts and isolate just the Solaris/non-Solaris portions and added readability. Also fixed the x86_64 targets for Solaris to not use the loader for linux, and fixed up Sparc64 and ia64 to use $(ARCH) instead of a hard-coded definition for the library. Bendiff -ruN qemu-ORIG/Makefile.target qemu/Makefile.target --- qemu-ORIG/Makefile.target 2007-03-18 19:23:31.0 -0400 +++ qemu/Makefile.target 2007-03-19 09:44:49.714657000 -0400 @@ -109,7 +109,11 @@ endif ifeq ($(ARCH),x86_64) -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + ifeq ($(CONFIG_SOLARIS),yes) +BASE_LDFLAGS+=-m64 + else +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif endif ifeq ($(ARCH),ppc) @@ -124,25 +128,28 @@ endif ifeq ($(ARCH),sparc) -ifeq ($(CONFIG_SOLARIS),yes) -BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 -BASE_LDFLAGS+=-m32 -OP_CFLAGS+=-fno-delayed-branch -fno-omit-frame-pointer -ffixed-i0 -else -BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g1 -ffixed-g2 -ffixed-g3 -ffixed-g6 -BASE_LDFLAGS+=-m32 -OP_CFLAGS+=-fno-delayed-branch -ffixed-i0 -HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat -# -static is used to avoid g1/g3 usage by the dynamic linker -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static -endif + BASE_CFLAGS+=-mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 + BASE_LDFLAGS+=-m32 + OP_CFLAGS+=-fno-delayed-branch -ffixed-i0 + ifeq ($(CONFIG_SOLARIS),yes) +OP_CFLAGS+=-fno-omit-frame-pointer + else +BASE_CFLAGS+=-ffixed-g1 -ffixed-g6 +HELPER_CFLAGS=$(CFLAGS) -ffixed-i0 -mflat +# -static is used to avoid g1/g3 usage by the dynamic linker +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -static + endif endif ifeq ($(ARCH),sparc64) -BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -BASE_LDFLAGS+=-m64 -BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld -OP_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 -fno-delayed-branch -ffixed-i0 + BASE_CFLAGS+=-mcpu=ultrasparc -m64 -ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 + DEFINES+=-D__sparc_v9__ + BASE_LDFLAGS+=-m64 + OP_CFLAGS+=-mcpu=ultrasparc -m64 -fno-delayed-branch -ffixed-i0 + ifneq ($(CONFIG_SOLARIS),yes) +BASE_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld +OP_CFLAGS+=-ffixed-g1 -ffixed-g4 -ffixed-g5 -ffixed-g7 + endif endif ifeq ($(ARCH),alpha) @@ -457,14 +464,24 @@ endif ifeq ($(ARCH),ia64) -VL_LDFLAGS+=-Wl,-G0 -Wl,-T,$(SRC_PATH)/ia64.ld + VL_LDFLAGS+=-Wl,-G0 -Wl,-T,$(SRC_PATH)/$(ARCH).ld endif ifeq ($(ARCH),sparc64) -VL_LDFLAGS+=-m64 -VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld + VL_LDFLAGS+=-m64 + ifneq ($(CONFIG_SOLARIS),yes) +VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif endif +ifeq ($(ARCH),x86_64) + VL_LDFLAGS+=-m64 + ifneq ($(CONFIG_SOLARIS),yes) +VL_LDFLAGS+=-Wl,-T,$(SRC_PATH)/$(ARCH).ld + endif +endif + + ifdef CONFIG_WIN32 SDL_LIBS := $(filter-out -mwindows, $(SDL_LIBS)) -mconsole endif ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] scsi patch
because (1) address of SCRATCHA is 0x34 (2) address from SCRATCHB to SCRATCHR are 0x5c ~ 0x9f you just see the code about part (2). I think the access code is right. 2007/3/19, Thiemo Seufer [EMAIL PROTECTED]: ? wrote: --- ../../tmp/qemu-0.9.0/hw/lsi53c895a.c2007-02-06 07:01: 54.0 +0800 +++ lsi53c895a.c2007-03-08 20:50:03.094098835 +0800 @@ -251,7 +251,7 @@ uint32_t ia; uint32_t sbc; uint32_t csbc; -uint32_t scratch[13]; /* SCRATCHA-SCRATCHR */ +uint32_t scratch[18]; /* SCRATCHA-SCRATCHR */ This still looks inconsistent. SCRATCHR suggests 18 available registers, but the code below handles only 17 scratch registers. Could you check what's the right thing there? Otherwise the patch looks good. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw lsi53c895a.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 14:49:29 Modified files: hw : lsi53c895a.c Log message: SCSI fixes, by Wang Cheng Yeh. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/lsi53c895a.c?cvsroot=qemur1=1.3r2=1.4 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu target-arm/exec.h target-mips/exec.h targe...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 14:47:40 Modified files: target-arm : exec.h target-mips: exec.h target-sparc : exec.h Log message: SPARC host fixes, by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/exec.h?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.18r2=1.19 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/exec.h?cvsroot=qemur1=1.16r2=1.17 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu monitor.c qemu-doc.texi sdl.c vl.c vl.h vnc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 15:17:08 Modified files: . : monitor.c qemu-doc.texi sdl.c vl.c vl.h vnc.c Log message: Add -name option, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/monitor.c?cvsroot=qemur1=1.67r2=1.68 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.135r2=1.136 http://cvs.savannah.gnu.org/viewcvs/qemu/sdl.c?cvsroot=qemur1=1.35r2=1.36 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.266r2=1.267 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.194r2=1.195 http://cvs.savannah.gnu.org/viewcvs/qemu/vnc.c?cvsroot=qemur1=1.12r2=1.13 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Correct setuid behavious in linux-user
The attached patch is needed to correctly emulate setuid executables.
With this change, and by making qemu be setuid root (and assumming all
of the risks and responsibilites of doing so), executables such as
/bin/su will be able to create the correct environment.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: linux-user/linuxload.c
===
RCS file: /sources/qemu/qemu/linux-user/linuxload.c,v
retrieving revision 1.2
diff -u -r1.2 linuxload.c
--- linux-user/linuxload.c 19 Nov 2006 20:29:35 - 1.2
+++ linux-user/linuxload.c 19 Mar 2007 15:09:50 -
@@ -78,6 +78,8 @@
if(bprm-e_uid != geteuid()) {
id_change = 1;
}
+} else {
+ seteuid(getuid());
}
/* Set-gid? */
@@ -91,6 +93,8 @@
if (!in_group_p(bprm-e_gid)) {
id_change = 1;
}
+} else {
+ setegid(getgid());
}
memset(bprm-buf, 0, sizeof(bprm-buf));
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] EABI fcntl on x86_64
When running ARM EABI binaries on x86_64, the target_eabi_flock64
structure is already padded correct so the padding is not needed.
This patch adds an #ifdef to only include the _pad member on 32-but
hosts.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: linux-user/syscall_defs.h
===
RCS file: /sources/qemu/qemu/linux-user/syscall_defs.h,v
retrieving revision 1.30
diff -u -r1.30 syscall_defs.h
--- linux-user/syscall_defs.h 22 Oct 2006 00:18:54 - 1.30
+++ linux-user/syscall_defs.h 19 Mar 2007 15:25:58 -
@@ -1409,7 +1409,9 @@
struct target_eabi_flock64 {
short l_type;
short l_whence;
+#if HOST_LONG_BITS == 32
int __pad;
+#endif
unsigned long long l_start;
unsigned long long l_len;
int l_pid;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] EABI fcntl on x86_64
On Monday 19 March 2007 15:30, Stuart Anderson wrote: When running ARM EABI binaries on x86_64, the target_eabi_flock64 structure is already padded correct so the padding is not needed. This patch adds an #ifdef to only include the _pad member on 32-but hosts. This is wrong. The struct is packed, so its layout should be independent of the host. How did you test your change? Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] EABI fcntl on x86_64
On [Mon, 19.03.2007 11:30], Stuart Anderson wrote:
When running ARM EABI binaries on x86_64, the target_eabi_flock64
structure is already padded correct so the padding is not needed.
This patch adds an #ifdef to only include the _pad member on 32-but
hosts.
Are you sure that problem is in padding? Please, look at my patch
in post [PATCH] fcntl64 fix.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
Content-Description: fcntl fix
Index: linux-user/syscall_defs.h
===
RCS file: /sources/qemu/qemu/linux-user/syscall_defs.h,v
retrieving revision 1.30
diff -u -r1.30 syscall_defs.h
--- linux-user/syscall_defs.h 22 Oct 2006 00:18:54 - 1.30
+++ linux-user/syscall_defs.h 19 Mar 2007 15:25:58 -
@@ -1409,7 +1409,9 @@
struct target_eabi_flock64 {
short l_type;
short l_whence;
+#if HOST_LONG_BITS == 32
int __pad;
+#endif
unsigned long long l_start;
unsigned long long l_len;
int l_pid;
signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] EABI fcntl on x86_64
On Mon, 19 Mar 2007, Paul Brook wrote: On Monday 19 March 2007 15:30, Stuart Anderson wrote: When running ARM EABI binaries on x86_64, the target_eabi_flock64 structure is already padded correct so the padding is not needed. This patch adds an #ifdef to only include the _pad member on 32-but hosts. This is wrong. The struct is packed, so its layout should be independent of the host. How did you test your change? I have a debian arm chroot setup. dpkg was unhappy, and I used gdb to observe that there seemed to an extra 4 bytes of data in the middle of the structure being passed into the host function. I missed Kirill's patch as it came across before I got back on the list, (and I missedit when I browsed the archive as well). Since I should be able to reproduce this, I'll test w/ his fix as well. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 15:58:31 Modified files: . : vl.c Log message: Improve -pidfile option, by Anthony Liguori. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.267r2=1.268 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] semctl support is incomplete
The attached patch finishes adding support for semctl(). This was
verified on ARM using the semctl test from LTP in the target.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: linux-user/syscall.c
===
RCS file: /sources/qemu/qemu/linux-user/syscall.c,v
retrieving revision 1.93
diff -u -r1.93 syscall.c
--- linux-user/syscall.c19 Mar 2007 13:32:45 - 1.93
+++ linux-user/syscall.c19 Mar 2007 15:40:57 -
@@ -1123,12 +1123,152 @@
uint32_t size;
} shm_regions[N_SHM_REGIONS];
+struct target_ipc_perm
+{
+target_long __key;
+target_ulong uid;
+target_ulong gid;
+target_ulong cuid;
+target_ulong cgid;
+unsigned short int mode;
+unsigned short int __pad1;
+unsigned short int __seq;
+unsigned short int __pad2;
+target_ulong __unused1;
+target_ulong __unused2;
+};
+
+struct target_semid_ds
+{
+ struct target_ipc_perm sem_perm;
+ target_ulong sem_otime;
+ target_ulong __unused1;
+ target_ulong sem_ctime;
+ target_ulong __unused2;
+ target_ulong sem_nsems;
+ target_ulong __unused3;
+ target_ulong __unused4;
+};
+
+static inline void target_to_host_ipc_perm(struct ipc_perm *ip,
+ target_ulong target_addr)
+{
+struct target_ipc_perm *target_ip;
+struct target_semid_ds *target_sd;
+
+lock_user_struct(target_sd, target_addr, 1);
+target_ip=(target_sd-sem_perm);
+ip-__key = tswapl(target_ip-__key);
+ip-uid = tswapl(target_ip-uid);
+ip-gid = tswapl(target_ip-gid);
+ip-cuid = tswapl(target_ip-cuid);
+ip-cgid = tswapl(target_ip-cgid);
+ip-mode = tswapl(target_ip-mode);
+unlock_user_struct(target_sd, target_addr, 0);
+}
+
+static inline void host_to_target_ipc_perm(target_ulong target_addr,
+ struct ipc_perm *host_ip)
+{
+struct target_ipc_perm *target_ip;
+struct target_semid_ds *target_sd;
+
+lock_user_struct(target_sd, target_addr, 0);
+target_ip = (target_sd-sem_perm);
+target_ip-__key = tswapl(host_ip-__key);
+target_ip-uid = tswapl(host_ip-uid);
+target_ip-gid = tswapl(host_ip-gid);
+target_ip-cuid = tswapl(host_ip-cuid);
+target_ip-cgid = tswapl(host_ip-cgid);
+target_ip-mode = tswapl(host_ip-mode);
+unlock_user_struct(target_sd, target_addr, 1);
+}
+
+static inline void target_to_host_semid_ds(struct semid_ds *host_sd,
+ target_ulong target_addr)
+{
+struct target_semid_ds *target_sd;
+
+lock_user_struct(target_sd, target_addr, 1);
+target_to_host_ipc_perm((host_sd-sem_perm),target_addr);
+host_sd-sem_nsems = tswapl(target_sd-sem_nsems);
+host_sd-sem_otime = tswapl(target_sd-sem_otime);
+host_sd-sem_ctime = tswapl(target_sd-sem_ctime);
+unlock_user_struct(target_sd, target_addr, 0);
+}
+
+static inline void host_to_target_semid_ds(target_ulong target_addr,
+ struct semid_ds *host_sd)
+{
+struct target_semid_ds *target_sd;
+
+lock_user_struct(target_sd, target_addr, 0);
+host_to_target_ipc_perm(target_addr,(host_sd-sem_perm));
+target_sd-sem_nsems = tswapl(host_sd-sem_nsems);
+target_sd-sem_otime = tswapl(host_sd-sem_otime);
+target_sd-sem_ctime = tswapl(host_sd-sem_ctime);
+unlock_user_struct(target_sd, target_addr, 1);
+}
+
union semun {
int val;
- struct senid_ds *buf;
+ struct semid_ds *buf;
unsigned short *array;
};
+union target_semun {
+ int val;
+ target_long buf;
+ target_long array;
+};
+
+static inline void target_to_host_semun(unsigned long cmd, union semun
*host_su,
+ target_ulong target_addr, struct
semid_ds *ds)
+{
+union target_semun *target_su;
+
+lock_user_struct(target_su, target_addr, 1);
+switch( cmd ) {
+ case IPC_STAT:
+ case IPC_SET:
+ target_to_host_semid_ds(ds,target_su-buf);
+ host_su-buf = ds;
+ break;
+ default:
+ host_su-array = tswapl(target_su-array);
+}
+unlock_user_struct(target_su, target_addr, 0);
+}
+
+static inline void host_to_target_semun(unsigned long cmd, target_ulong
target_addr,
+ union semun *host_su, struct
semid_ds *ds)
+{
+union target_semun *target_su;
+
+lock_user_struct(target_su, target_addr, 0);
+switch( cmd ) {
+ case IPC_STAT:
+ case IPC_SET:
+ host_to_target_semid_ds(target_su-buf,ds);
+ break;
+default:
+ target_su-array = tswapl(host_su-array);
+}
+
Re: [Qemu-devel] [PATCH] Add info commands for serial/parallel devices
Anthony Liguori wrote:
Howdy,
The following patch adds an info serial and an info parallel command.
Besides providing useful information (especially for the serial port),
it provides a method for management tools to connect to a running VM and
what character devices the serial/parallel ports have been redirected to.
The format of the info is similar to that of info block.
[snip]
diff -r 18e99d1e8814 vl.c
--- a/vl.cSat Mar 03 21:18:48 2007 -0600
+++ b/vl.cSat Mar 03 21:33:07 2007 -0600
@@ -2884,66 +2884,73 @@ CharDriverState *qemu_chr_open(const cha
CharDriverState *qemu_chr_open(const char *filename)
{
const char *p;
+CharDriverState *chr;
if (!strcmp(filename, vc)) {
-return text_console_init(display_state);
+chr = text_console_init(display_state);
} else if (!strcmp(filename, null)) {
-return qemu_chr_open_null();
+chr = qemu_chr_open_null();
} else
if (strstart(filename, tcp:, p)) {
-return qemu_chr_open_tcp(p, 0, 0);
+chr = qemu_chr_open_tcp(p, 0, 0);
} else
if (strstart(filename, telnet:, p)) {
-return qemu_chr_open_tcp(p, 1, 0);
+chr = qemu_chr_open_tcp(p, 1, 0);
} else
if (strstart(filename, udp:, p)) {
-return qemu_chr_open_udp(p);
+chr = qemu_chr_open_udp(p);
} else
if (strstart(filename, mon:, p)) {
CharDriverState *drv = qemu_chr_open(p);
if (drv) {
drv = qemu_chr_open_mux(drv);
monitor_init(drv, !nographic);
-return drv;
-}
-printf(Unable to open driver: %s\n, p);
-return 0;
+chr = drv;
+} else {
+ printf(Unable to open driver: %s\n, p);
+ return 0;
+ }
} else
#ifndef _WIN32
if (strstart(filename, unix:, p)) {
- return qemu_chr_open_tcp(p, 0, 1);
+ chr = qemu_chr_open_tcp(p, 0, 1);
} else if (strstart(filename, file:, p)) {
-return qemu_chr_open_file_out(p);
+chr = qemu_chr_open_file_out(p);
} else if (strstart(filename, pipe:, p)) {
-return qemu_chr_open_pipe(p);
+chr = qemu_chr_open_pipe(p);
} else if (!strcmp(filename, pty)) {
-return qemu_chr_open_pty();
+chr = qemu_chr_open_pty();
} else if (!strcmp(filename, stdio)) {
-return qemu_chr_open_stdio();
+chr = qemu_chr_open_stdio();
} else
#endif
#if defined(__linux__)
if (strstart(filename, /dev/parport, NULL)) {
-return qemu_chr_open_pp(filename);
+chr = qemu_chr_open_pp(filename);
} else
if (strstart(filename, /dev/, NULL)) {
-return qemu_chr_open_tty(filename);
+chr = qemu_chr_open_tty(filename);
} else
#endif
#ifdef _WIN32
if (strstart(filename, COM, NULL)) {
-return qemu_chr_open_win(filename);
+chr = qemu_chr_open_win(filename);
} else
if (strstart(filename, pipe:, p)) {
-return qemu_chr_open_win_pipe(p);
+chr = qemu_chr_open_win_pipe(p);
} else
if (strstart(filename, file:, p)) {
-return qemu_chr_open_win_file_out(p);
-}
+chr = qemu_chr_open_win_file_out(p);
+} else
#endif
{
return NULL;
}
+
+if (chr)
+ chr-filename = strdup(filename);
+
+return chr;
Why is this part needed?
}
void qemu_chr_close(CharDriverState *chr)
diff -r 18e99d1e8814 vl.h
--- a/vl.hSat Mar 03 21:18:48 2007 -0600
+++ b/vl.hSat Mar 03 21:33:07 2007 -0600
@@ -307,6 +307,7 @@ typedef struct CharDriverState {
void *opaque;
int focus;
QEMUBH *bh;
+char *filename;
} CharDriverState;
const char * ?
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] EABI fcntl on x86_64
On Mon, 19 Mar 2007, Stuart Anderson wrote: I have a debian arm chroot setup. Just to clarify, this is from the applieddata.net repository, not the normal debian one (which is not eabi). Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Automatically eject CD-ROM disk in Linux host system
Yu, Xiaoyang wrote: Hi, I wrote a patch to automatically eject a physical CD-ROM disk when: * Issue eject command in monitor console, or * Issue eject command in Linux guest system, or * In Windows guest system, press the right mouse button above CD-ROM icon, then select eject. This is patch is based on QEMU 0.8.2 in Xen 3.0.3, and works on Linux host system. system() is a horrible way to do this. Consider using SDL_CDEject() instead. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 16:36:43 Modified files: . : vl.c Log message: Close file descriptors when execing network tap setup script, by Daniel P. Berrange. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.268r2=1.269 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/fpu softfloat-native.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 16:46:07 Modified files: fpu: softfloat-native.c Log message: trunc() for Solaris 9 / SPARC, by Juergen Keil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/fpu/softfloat-native.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] [PATCH] fcntl64 fix
Kirill A. Shutemov wrote:
TARGET_F_*64 should be used instead of F_*64, because on 64-bit host
systems F_GETLK == F_GETLK64(same for SETLK and SETLKW), so we cannot
determinate if it's a long lock or not on a target 32-bit system.
Patch in the attachment.
P.S. Please, review my privious patches, which I have added description
recently. Or should I repost it?
diff -uNr qemu-0.9.0.cvs20070304.orig/linux-user/syscall.c
qemu-0.9.0.cvs20070304/linux-user/syscall.c
--- qemu-0.9.0.cvs20070304.orig/linux-user/syscall.c 2007-03-09 20:08:59
+0200
+++ qemu-0.9.0.cvs20070304/linux-user/syscall.c 2007-03-09 20:09:54
+0200
@@ -4063,7 +4063,7 @@
#endif
switch(arg2) {
-case F_GETLK64:
+case TARGET_F_GETLK64:
ret = get_errno(fcntl(arg1, arg2, fl));
This changes the bug from checking the wrong flag to (potentially)
passing down the wrong flag...
if (ret == 0) {
#ifdef TARGET_ARM
@@ -4089,8 +4089,8 @@
}
break;
-case F_SETLK64:
-case F_SETLKW64:
+case TARGET_F_SETLK64:
+case TARGET_F_SETLKW64:
#ifdef TARGET_ARM
if (((CPUARMState *)cpu_env)-eabi) {
lock_user_struct(target_efl, arg3, 1);
Likewise here. We should always check TARGET_* flags and pass down the
corresponding host flag.
Thiemo
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
My initial fix was before I started using LTP, and just took care of a single case that was holding me up. Now I have run the fcntl tests in LTP on ARM (both oABI and EABI) and there are a lot of failures indicating that there is a lot more work to be done yet on fcntl(). I'll take a look into it, and probably resubmit a bigger patch later. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw rtl8139.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 18:20:28 Modified files: hw : rtl8139.c Log message: Fix big endian host operation, by Ben Taylor and Igor Kovalenko. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/rtl8139.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] KQEMU Darwin port status?
On 19 Mar 2007, at 08:49, Mike Kronenberg wrote: I have made a empty kext and a dummy client to do some tests on this topics. Boundary crossing is working well, so by now the kext part is ready. http://www.kronenberg.org/files/kqemu_poc.zip Neat, thanks. Unfortunately, Apple decided to remove/hide some of the vm_* API (especially vm_map_(un)wire in Tiger. (It was available on Panther. vm_map_user_pageable was never part of Darwin). So any suggestions on how to lock user pages in Darwin would be very welcome. Mmm, that's rather unhelpful. From my own reading, it looks like the Apple-approved way of doing this would be to use an IOMemoryDescriptor: initWithAddress() would initialise one which represents the appropriate lump of application-space memory (vm_address_t, length, direction [1] and task_t [2]); prepare() and complete() wire and unwire it respectively; and presumably getPhysicalSegment() covers the 'get physical address' part. Using this probably requires making the extension a I/O Kit Device Driver, but that's just a few extra methods to implement AFAICT. I'll see if I can make a trivial test for this approach. Phil 1. kIODirectionOutIn (or InOut) appears suitable here---the kernel- side IOKit headers show both as equivilent to VM_PROT_READ | VM_PROT_WRITE 2. Looking at the FreeBSD version, that's just current process, so literally current_task() ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Implement division by 0 trap on the Sparc target
Hi all,
A division by 0 currently does not generate a trap on the Sparc target,
instead it crashes QEMU. The patch below fixes that.
Bye,
Aurelien
Index: target-sparc/op.c
===
RCS file: /sources/qemu/qemu/target-sparc/op.c,v
retrieving revision 1.24
diff -u -d -p -r1.24 op.c
--- target-sparc/op.c 10 Feb 2007 22:58:02 - 1.24
+++ target-sparc/op.c 19 Mar 2007 18:49:20 -
@@ -671,6 +671,11 @@ void OPPROTO op_udiv_T1_T0(void)
x0 = T0 | ((uint64_t) (env-y) 32);
x1 = T1;
+
+if (x1 == 0) {
+raise_exception(TT_DIV_ZERO);
+}
+
x0 = x0 / x1;
if (x0 0x) {
T0 = 0x;
@@ -689,6 +694,11 @@ void OPPROTO op_sdiv_T1_T0(void)
x0 = T0 | ((int64_t) (env-y) 32);
x1 = T1;
+
+if (x1 == 0) {
+raise_exception(TT_DIV_ZERO);
+}
+
x0 = x0 / x1;
if ((int32_t) x0 != x0) {
T0 = x0 0? 0x8000: 0x7fff;
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-sparc op.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 19:16:00 Modified files: target-sparc : op.c Log message: Fix qemu crash due to sparc division-by-zero, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.24r2=1.25 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/linux-user main.c
On Mon, 2007-03-19 at 12:16 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/03/19 12:16:29 Modified files: linux-user : main.c Log message: Support -cpu selection for mips usermode emulation. Fix segfault when dispaying the -cpu list help. Could you tell more about the segfault ? exit is used at many other places without any problem and furthermore I did not experiment any crash while testing the PowerPC target with the initial patch, so ? (I'd really like to understand...) -- J. Mayer [EMAIL PROTECTED] Never organized ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PATCH: arm guest on Solaris/Sparc host
This patch was suggested by Juergen Keil. It prevents a crash by qemu when running the arm-test on Solaris/Sparc. Removing the previous arm patch for sparc uncovered a use of global registers o0-05 which hadn't been defined previously. Ben--- qemu-ORIG/cpu-exec.c 2007-03-16 19:58:11.0 -0400 +++ qemu/cpu-exec.c 2007-03-19 15:14:21.930962000 -0400 @@ -648,6 +648,7 @@ : /* no outputs */ : r (gen_func) : i0, i1, i2, i3, i4, i5, + o0, o1, o2, o3, o4, o5, l0, l1, l2, l3, l4, l5, l6, l7); #elif defined(__arm__) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/linux-user main.c
J. Mayer wrote: On Mon, 2007-03-19 at 12:16 +, Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 12:16:29 Modified files: linux-user : main.c Log message: Support -cpu selection for mips usermode emulation. Fix segfault when dispaying the -cpu list help. Could you tell more about the segfault ? It segfaulted for me (on ppc/linux) after printing the help list. exit is used at many other places without any problem and furthermore I did not experiment any crash while testing the PowerPC target with the initial patch, so ? (I'd really like to understand...) I didn't really debug it, but I noticed the other branch in the conditional uses _exit() instead of exit(). With that change, the segfault disappeared. I figure we have an atexit/on_exit call somwhere which tries to use data which isn't initialized at that point. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
On Mon, Mar 19, 2007 at 06:54:35PM +, Philip Boulain wrote: Mmm, that's rather unhelpful. From my own reading, it looks like the Apple-approved way of doing this would be to use an IOMemoryDescriptor: initWithAddress() would initialise one which There was just a discussion relating to this on the darwin-kernel list, you may wish to review the archive. (The thread starts at http://lists.apple.com/archives/Darwin-kernel/2007/Mar/msg00010.html). DF ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu cpu-exec.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 20:39:50 Modified files: . : cpu-exec.c Log message: Fix call to generated code on SPARC, by Juergen Keil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.94r2=1.95 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] softfloat missing functions
Note that float64_to_uint64 functions are not correct, as they won't
return results between INT64_MAX and UINT64_MAX. Hope someone may know
the proper solution for this.
How about this?
J
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
uint64_t res;
int64_t v;
if (isinf(a) || isnan(a)) {
return special value ( maybe 163 ?)
}
else
if (a 0.0 || a (float64)UINT64_MAX) {
return out-of-range value, whatever that is
} else {
a += (float64) INT64_MIN; // move a downwards
v = llrint(a); // convert
v -= INT64_MIN;// move v back up
return v;
}
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/linux-user main.c
On Monday 19 March 2007 21:13:12 Thiemo Seufer wrote: J. Mayer wrote: On Mon, 2007-03-19 at 12:16 +, Thiemo Seufer wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Thiemo Seufer ths 07/03/19 12:16:29 Modified files: linux-user : main.c Log message: Support -cpu selection for mips usermode emulation. Fix segfault when dispaying the -cpu list help. Could you tell more about the segfault ? It segfaulted for me (on ppc/linux) after printing the help list. exit is used at many other places without any problem and furthermore I did not experiment any crash while testing the PowerPC target with the initial patch, so ? (I'd really like to understand...) I didn't really debug it, but I noticed the other branch in the conditional uses _exit() instead of exit(). With that change, the segfault disappeared. I figure we have an atexit/on_exit call somwhere which tries to use data which isn't initialized at that point. Maybe that's related to the problem i've got (in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00110.html ). There is some piece of code in main.c which mess around libc initialization exit and were making my qemu-i386 segfault really early. It seems it was designed to avoid a bug in some versions of glibc. I attach the simple patch I've made to avoid that. It may need adjustements since I don't know enough about libc internals on initialization to be sure that's the correct fix - I would be deeply interested in some input/comments on this problem. Pierre Palatin Index: linux-user/main.c === --- linux-user/main.c (révision 527) +++ linux-user/main.c (copie de travail) @@ -44,7 +44,7 @@ /* for recent libc, we add these dummy symbols which are not declared when generating a linked object (bug in ld ?) */ -#if (__GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ = 3)) !defined(CONFIG_STATIC) +#if (__GLIBC__ == 2 __GLIBC_MINOR__ == 3) !defined(CONFIG_STATIC) long __preinit_array_start[0]; long __preinit_array_end[0]; long __init_array_start[0]; ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Thank you, Paul, for your explanation which clarified Thiemo's statement.
I now checked how my published test code could contribute to a DoS attack.
Current QEMU HEAD:
* The code hangs as I wrote before. This is from a user's point of view.
Hanging means, that the test process runs in an infinite loop using any
CPU time it can get in the virtual machine. QEMU uses all available
CPU time from the host CPU.
With single stepping enabled or in the debugger, the test code won't
hang but give a random result.
Patched QEMU HEAD (see appended patch file):
* The code works in a well defined way. An optional message in the log file
will show the faulty statement. It won't amount to a DoS because it
is disabled by default.
Using single stepping, the test code's result remains the same.
So the patch improves the situation. Although it does not model the real
behaviour of an AR7 cpu, it solved my problem with a Zyxel firmware.
Maybe you can apply at least part of it or even improve and extend it to
other branch operations.
Thank you
Stefan
Details of the patch
* show optional message when any branch bits in hflags are already set
before a branch instruction is generated (so we have a branch in the
delay slot)
* mask branch bits before setting new ones (implemented only for the jr
statement because this was the one I needed and examined)
- this part could be improved
* make gen_intermediate_code_internal static (might improve compiler
optimizations and is completely unrelated to the other two changes)
Paul Brook wrote:
So an emulation has several options:
1. Show undefined behaviour (this is what it does today).
2. Emulate the behaviour of existing CPUs as far as possible.
As different CPUs behave different, this must depend on the
current CPU.
3. Display an error message.
(3) is bad, as it amounts to a DoS.
DoS = Denial of Service? Then (1) is some kind of DoS, because QEMU hangs
with code which works on real hardware. I don't understand why an
error message (something printed to stdout or stderr like other boot
messages of QEMU) amounts to a DoS.
It's not the same thing at all. In both cases buggy code crashes. I
expect
this could also happen on a fair proportion of real MIPS hardware. It may
even happen on AR7 hardware is a interrupt or fault happens to trigger
at the
wrong time.
With (1) the buggy program crashes, and the rest of the machine keeps
going.
With (3) an unprivileged user can effectively bring the whole machine
down
just by executing invalid code sequences.
Paul
Index: target-mips/translate.c
===
RCS file: /sources/qemu/qemu/target-mips/translate.c,v
retrieving revision 1.37
diff -u -b -B -u -r1.37 translate.c
--- target-mips/translate.c 18 Mar 2007 00:30:29 - 1.37
+++ target-mips/translate.c 19 Mar 2007 20:26:31 -
@@ -1371,6 +1371,13 @@
target_ulong btarget;
int blink, bcond;
+if (ctx-hflags MIPS_HFLAG_BMASK) {
+if (loglevel CPU_LOG_TB_IN_ASM) {
+fprintf(logfile,
+undefined branch in delay slot at pc 0x%08x\n, ctx-pc);
+}
+}
+
btarget = -1;
blink = 0;
bcond = 0;
@@ -1480,7 +1487,7 @@
MIPS_DEBUG(jal %08x, btarget);
break;
case OPC_JR:
-ctx-hflags |= MIPS_HFLAG_BR;
+ctx-hflags = ((ctx-hflags ~MIPS_HFLAG_BMASK) | MIPS_HFLAG_BR);
MIPS_DEBUG(jr %s, regnames[rs]);
break;
case OPC_JALR:
@@ -4999,7 +5006,7 @@
}
}
-int gen_intermediate_code_internal (CPUState *env, TranslationBlock *tb,
+static int gen_intermediate_code_internal (CPUState *env, TranslationBlock *tb,
int search_pc)
{
DisasContext ctx, *ctxp = ctx;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] softfloat missing functions
On Mon, 2007-03-19 at 20:37 +, Julian Seward wrote:
Note that float64_to_uint64 functions are not correct, as they won't
return results between INT64_MAX and UINT64_MAX. Hope someone may know
the proper solution for this.
How about this?
Yes, it seems to be the correct way, but thinking more about the
problem, it appeared to me that the implementation could be even easier
than yours. It seems to me that this may be sufficient:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = llrint(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
{
int64_t v;
v = (int64_t)(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
For not-native softfloat, this gives:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = int64_to_float64(INT64_MIN STATUS_VAR);
v = float64_to_int64((a + v) STATUS_VAR);
return v - INT64_MIN;
}
uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
{
int64_t v;
v = int64_to_float64(INT64_MIN STATUS_VAR);
v = float64_to_int64_round_to_zero((a + v) STATUS_VAR);
return v - INT64_MIN;
}
This should also give the correct result for NaN and overflows, if we
rely to the fact float64_to_int64 is correct. Please tell me if I'm
wrong !
--
J. Mayer [EMAIL PROTECTED]
Never organized
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/linux-user main.c
Pierre Palatin wrote: On Monday 19 March 2007 21:13:12 Thiemo Seufer wrote: J. Mayer wrote: On Mon, 2007-03-19 at 12:16 +, Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 12:16:29 Modified files: linux-user : main.c Log message: Support -cpu selection for mips usermode emulation. Fix segfault when dispaying the -cpu list help. Could you tell more about the segfault ? It segfaulted for me (on ppc/linux) after printing the help list. exit is used at many other places without any problem and furthermore I did not experiment any crash while testing the PowerPC target with the initial patch, so ? (I'd really like to understand...) I didn't really debug it, but I noticed the other branch in the conditional uses _exit() instead of exit(). With that change, the segfault disappeared. I figure we have an atexit/on_exit call somwhere which tries to use data which isn't initialized at that point. Maybe that's related to the problem i've got (in http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00110.html ). There is some piece of code in main.c which mess around libc initialization exit and were making my qemu-i386 segfault really early. It seems it was designed to avoid a bug in some versions of glibc. I attach the simple patch I've made to avoid that. It may need adjustements since I don't know enough about libc internals on initialization to be sure that's the correct fix - I would be deeply interested in some input/comments on this problem. Pierre Palatin Index: linux-user/main.c === --- linux-user/main.c (révision 527) +++ linux-user/main.c (copie de travail) @@ -44,7 +44,7 @@ /* for recent libc, we add these dummy symbols which are not declared when generating a linked object (bug in ld ?) */ -#if (__GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ = 3)) !defined(CONFIG_STATIC) +#if (__GLIBC__ == 2 __GLIBC_MINOR__ == 3) !defined(CONFIG_STATIC) long __preinit_array_start[0]; long __preinit_array_end[0]; long __init_array_start[0]; binutils' ld had a bug a while ago, this looks like a workaround for it (which means the check for glibc is wrong, and there's no easy way to do it right). Commenting out that code made no difference to me. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Stefan Weil wrote: Thank you, Paul, for your explanation which clarified Thiemo's statement. I now checked how my published test code could contribute to a DoS attack. Current QEMU HEAD: * The code hangs as I wrote before. This is from a user's point of view. Hanging means, that the test process runs in an infinite loop using any CPU time it can get in the virtual machine. QEMU uses all available CPU time from the host CPU. This is a bug in qemu, since it doesn't match CPU behaviour. While the architecture spec claims UNPREDICTABLE, such a code sequence shouldn't impede other processes on the same CPU. Throwing an RI exception should suffice for the general case (i.e. not AR7). With single stepping enabled or in the debugger, the test code won't hang but give a random result. Patched QEMU HEAD (see appended patch file): * The code works in a well defined way. An optional message in the log file will show the faulty statement. It won't amount to a DoS because it is disabled by default. Sorry, but I missed the well defined. What does the jump in the branch delay slot exactly _do_ now? Where does the PC point to when it was a conditional branch which wasn't taken? [snip] * show optional message when any branch bits in hflags are already set before a branch instruction is generated (so we have a branch in the delay slot) Agreed on that, since it is debug output which is only written when asked for. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu target-m68k/translate.c target-mips/transl...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 21:46:06 Modified files: target-m68k: translate.c target-mips: translate.c target-ppc : translate.c target-sh4 : translate.c Log message: Define gen_intermediate_code_internal as static inline. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.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/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/19 22:15:30 Modified files: target-mips: translate.c Log message: Barf on branches/jumps in branch delay slots. Spotted by Stefan Weil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.38r2=1.39 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] KQEMU Darwin port status?
On 19 Mar 2007, at 20:23, Derek Fawcus wrote: There was just a discussion relating to this on the darwin-kernel list, you may wish to review the archive. (The thread starts at http://lists.apple.com/archives/Darwin-kernel/ 2007/Mar/msg00010.html). Thanks; looking at this post, I'm probably barking up the right tree: http://lists.apple.com/archives/Darwin-kernel/2007/Mar/msg00031.html Unfortunately, rather than confirm or deny this path of reasoning, the others got unhelpfully uppity. =/ LionsPhil ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Thiemo Seufer wrote: [snip] Patched QEMU HEAD (see appended patch file): * The code works in a well defined way. An optional message in the log file will show the faulty statement. It won't amount to a DoS because it is disabled by default. Sorry, but I missed the well defined. What does the jump in the branch delay slot exactly _do_ now? Where does the PC point to when it was a conditional branch which wasn't taken? I committed something which cover the rest of your patch, and throws now a RI exception for branch-in-branch-delay-slot. For the AR7 case, could you - add AR7 as a CPU type - handle the interesting cases for AR7 only, after verifying the cornercase behaviour of qemu and real hardware is consistent. The cornercases which come to mind: - conditional vs. unconditional branches - the various condition types - taken vs. non-taken branches - linked vs. non-linked branches - likely vs. non-likely branches - the side effects of j / jal in the delayslot - the value of PC/ra (if it changes) I don't ask for an exhaustive analysis, I just want to see the cases of interest covered, so we can be reasonably sure the qemu results will be useful for other AR7 users as well. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Fwd: Re: [Qemu-devel] [PATCH] softfloat missing functions]
Repost: looks like this message never reached the list
Forwarded Message
From: J. Mayer [EMAIL PROTECTED]
To: Julian Seward [EMAIL PROTECTED]
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] softfloat missing functions
Date: Mon, 19 Mar 2007 22:10:14 +0100
On Mon, 2007-03-19 at 20:37 +, Julian Seward wrote:
Note that float64_to_uint64 functions are not correct, as they won't
return results between INT64_MAX and UINT64_MAX. Hope someone may know
the proper solution for this.
How about this?
Yes, it seems to be the correct way, but thinking more about the
problem, it appeared to me that the implementation could be even easier
than yours. It seems to me that this may be sufficient:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = llrint(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
{
int64_t v;
v = (int64_t)(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
For not-native softfloat, this gives:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = int64_to_float64(INT64_MIN STATUS_VAR);
v = float64_to_int64((a + v) STATUS_VAR);
return v - INT64_MIN;
}
uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
{
int64_t v;
v = int64_to_float64(INT64_MIN STATUS_VAR);
v = float64_to_int64_round_to_zero((a + v) STATUS_VAR);
return v - INT64_MIN;
}
This should also give the correct result for NaN and overflows, if we
rely to the fact float64_to_int64 is correct. Please tell me if I'm
wrong !
--
J. Mayer [EMAIL PROTECTED]
Never organized
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] softfloat missing functions
Thinking about this more, you ask is this correct, but that
is only meaningful if you say what the specification is.
Correct relative to what?
Yes, it seems to be the correct way, but thinking more about the
problem, it appeared to me that the implementation could be even easier
than yours. It seems to me that this may be sufficient:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = llrint(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
If a is NaN then so is the argument to llrint. 'man llrint' says:
If x is infinite or NaN, or if the rounded value is
outside the range of the return type, the numeric result
is unspecified.
So then float64_to_uint64 produces an unspecified result.
It seems to me much safer to test and handle NaN, Inf and
out-of-range values specially. However, even that does not help
unless you say what the specification is.
J
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] softfloat missing functions
On Mon, 2007-03-19 at 22:53 +, Julian Seward wrote:
Thinking about this more, you ask is this correct, but that
is only meaningful if you say what the specification is.
Correct relative to what?
Yes, it seems to be the correct way, but thinking more about the
problem, it appeared to me that the implementation could be even easier
than yours. It seems to me that this may be sufficient:
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
{
int64_t v;
v = llrint(a + (float64)INT64_MIN);
return v - INT64_MIN;
}
If a is NaN then so is the argument to llrint. 'man llrint' says:
If x is infinite or NaN, or if the rounded value is
outside the range of the return type, the numeric result
is unspecified.
So then float64_to_uint64 produces an unspecified result.
It seems to me much safer to test and handle NaN, Inf and
out-of-range values specially. However, even that does not help
unless you say what the specification is.
Well, you are right, but the function float64_to_int64 acts the same way
in that code.
If we want to follow IEEE compliance, we have to use the softfloat
functions instead, not the softfloat-native ones. Or we should sanitize
the whole softfloat.c code, to be consistent, it seems.
Here's an updated patch, with two more functions. The added functions
are:
float32 uint32_to_float32(unsigned int v STATUS_PARAM)
float64 uint32_to_float64(unsigned int v STATUS_PARAM)
float32 uint64_to_float32( uint64_t v STATUS_PARAM)
float64 uint64_to_float64( uint64_t v STATUS_PARAM)
unsigned int float32_to_uint32( float32 a STATUS_PARAM)
unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM)
unsigned int float64_to_uint32( float64 a STATUS_PARAM)
unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM)
uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
Note that some of those functions already exist in softfloat.c but not
in softfloat-native.c.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: fpu/softfloat-native.c
===
RCS file: /sources/qemu/qemu/fpu/softfloat-native.c,v
retrieving revision 1.6
diff -u -d -d -p -r1.6 softfloat-native.c
--- fpu/softfloat-native.c 28 Oct 2006 19:27:11 - 1.6
+++ fpu/softfloat-native.c 19 Mar 2007 23:05:29 -
@@ -59,11 +59,21 @@ float32 int32_to_float32(int v STATUS_PA
return (float32)v;
}
+float32 uint32_to_float32(unsigned int v STATUS_PARAM)
+{
+return (float32)v;
+}
+
float64 int32_to_float64(int v STATUS_PARAM)
{
return (float64)v;
}
+float64 uint32_to_float64(unsigned int v STATUS_PARAM)
+{
+return (float64)v;
+}
+
#ifdef FLOATX80
floatx80 int32_to_floatx80(int v STATUS_PARAM)
{
@@ -74,10 +84,18 @@ float32 int64_to_float32( int64_t v STAT
{
return (float32)v;
}
+float32 uint64_to_float32( uint64_t v STATUS_PARAM)
+{
+return (float32)v;
+}
float64 int64_to_float64( int64_t v STATUS_PARAM)
{
return (float64)v;
}
+float64 uint64_to_float64( uint64_t v STATUS_PARAM)
+{
+return (float64)v;
+}
#ifdef FLOATX80
floatx80 int64_to_floatx80( int64_t v STATUS_PARAM)
{
@@ -132,6 +150,37 @@ floatx80 float32_to_floatx80( float32 a
}
#endif
+unsigned int float32_to_uint32( float32 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = llrintf(a);
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+unsigned int float32_to_uint32_round_to_zero( float32 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = (int64_t)a;
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+
/*
| Software IEC/IEEE single-precision operations.
**/
@@ -218,6 +267,53 @@ float128 float64_to_float128( float64 a
}
#endif
+unsigned int float64_to_uint32( float64 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = llrint(a);
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+unsigned int float64_to_uint32_round_to_zero( float64 a STATUS_PARAM)
+{
+int64_t v;
+unsigned int res;
+
+v = (int64_t)a;
+if (v 0) {
+res = 0;
+} else if (v 0x) {
+res = 0x;
+} else {
+res = v;
+}
+return res;
+}
+uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
+{
+int64_t v;
+
+v = llrint(a + (float64)INT64_MIN);
+
+return v - INT64_MIN;
+}
+uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
+{
+int64_t v;
+
+v = (int64_t)(a +
Re: [Qemu-devel] KQEMU Darwin port status?
Mike Kronenberg wrote: So any suggestions on how to lock user pages in Darwin would be very welcome. Philip Boulain wrote: Thanks; looking at this post, I'm probably barking up the right tree Right. I've cobbled up the aformentioned prototype, and it working insofar that the modified and now-leaky version of Mike's test client is allocating sequential lumps of memory when you bash the EXEC button, and I'm getting plausible sequential physical addresses out; I can also read/write to the memory via the IOMemoryDescriptor (the client initialises the first uint8 of the 'lump' to 23, which will appear in the system log/console; the kext writes 42 to it, which will appear in the client). http://www.ecs.soton.ac.uk/~prb/junk/qemu-devel-darwin- kqemu-19mar07.tar.bz2 (1934KB) Summary of changes to Mike's earlier example: - 'transporter' struct now has a 'uint8_t* lump_of_ram;' member, to act as some application-allocated memory (it mallocs (and never frees, ahem) 2K each EXEC ioctl). - I dropped Mike's KEXT code into the HelloIOKit example, so that it does all the IO KEXT initialisation. I'm not convinced that this is actually necessary. A side effect is that 'kqemu.ext' is now called 'HelloIOKit.ext'. Please bear with the quick and nasty prototype. ;) - The KQEMU_EXEC ioctl handling case now: - Constructs a IOGeneralMemoryDescriptor and initialises it to point to the lump_of_ram in the transporter struct - 'Prepares' the Descriptor. I believe that this is performing the required locking: This involves paging in the memory, if necessary, and wiring it down for the duration of the transfer. [1] - Prints the physical address to the system log, and does the aformentioned read/write - 'Completes' the Descriptor (unlocking) - Destructs (pedantically: unreferences) the IOGeneralMemoryDescriptor [De]constructing a fresh IOGMD each time is rough-prototype-code garbage. One can be recycled by just calling initWithAddress() again on it---at a _glance_, it looks like the kqemu_instance struct would be a sensible place to put it. Phil 1. http://developer.apple.com/documentation/Darwin/Reference/ KernelIOKitFramework/IOMemoryDescriptor/Classes/IOMemoryDescriptor/ index.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fcntl64 fix
On Mon, 19 Mar 2007, Stuart Anderson wrote:
My initial fix was before I started using LTP, and just took care of a
single case that was holding me up. Now I have run the fcntl tests in
LTP on ARM (both oABI and EABI) and there are a lot of failures indicating
that there is a lot more work to be done yet on fcntl().
I'll take a look into it, and probably resubmit a bigger patch later.
One more small fix to repack a structure from taget - host before using
it clears up most of the fcntl() errors that showed up in LTP. This is
one of those that probably doesn't happen when runngin 32 on 32, but I'm
running 32 on 64.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149--- linux-user/syscall.c.orig 2007-03-20 01:25:39.0 -0400
+++ linux-user/syscall.c2007-03-20 02:32:39.0 -0400
@@ -2107,6 +2107,13 @@
switch(cmd) {
case TARGET_F_GETLK:
+lock_user_struct(target_fl, arg, 1);
+fl.l_type = tswap16(target_fl-l_type);
+fl.l_whence = tswap16(target_fl-l_whence);
+fl.l_start = tswapl(target_fl-l_start);
+fl.l_len = tswapl(target_fl-l_len);
+fl.l_pid = tswapl(target_fl-l_pid);
+unlock_user_struct(target_fl, arg, 0);
ret = fcntl(fd, cmd, fl);
if (ret == 0) {
lock_user_struct(target_fl, arg, 0);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
