Re: [Qemu-devel] USB Tablet Emulation + VNC patch..
Troy Benjegerdes wrote: Now, does anyone have instructions on how to get Win2k installed and updated to the latest set of security patches? I can get service pack 4 installed, but running windowsupdate seems to never work right. If I run it up with -win2k-hack then windowsupdate works fine.. Here is what I did though (although variants have worked) Install win2k-sp4 run windowsupdate and ignore the warning about ie6, let it install the updated windows-update component. Reboot, install ie6, reboot, then run windows-update and install all the patches. All of this with win2k-hack enabled or it won't work.. and the updated win2k-hack from Leo so it works with dma.. I'm still stuck with windowsupdate not working.. I am finding now that after I go through installing win2k, and running ie5, I can see it has 56 bit encryption. But after installing service pack 3 and service pack 4, IE says '0-bit encryption'. Better to download SP4 complete.. don't use windows update to install the service packs, just install and load SP4 without interracting with the net at all.. sp3 does strange things.. -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] gnu-c99-math.h file
Chris Bagwell <[EMAIL PROTECTED]> wrote: > I just upgraded to current CVS to get all the changes submitted today. > The solaris port commits seems to have added a #include "gnu-c99-math.h" > file to fpu/softfloat-native.h. Apologies. That should have been isolated with a #ifdef __sun__ #include "gnu-c99-math.h" #endif > > This file doesn't exist on my Fedora Core 5 system with gcc32 installed > for compatibility. The mailing archive mentions something about this > missing file being a custom file for the solaris port. Should that file > only be referenced under solaris? correct. I rechecked the patch I sent to Fabrice and the gnu-c99-math.h file is there. > Qemu appears to compile fine on linux if I just comment that line out. > > Chris The following patch and file will correct the issue for solaris and non-solaris system alike. Fabrice - can we get this added to CVS? Regards, Ben fpu-softfloat-patch.diff Description: Binary data gnu-c99-math.h Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] fpu/softfloat-native.h incorrectly includes missing header (gnu-c99-math.h) in latest CVS
Damien Mascord <[EMAIL PROTECTED]> wrote: > Hi, > > Seems as though a missing header is being included in this file. > > Removing it enables qemu to compile cleanly, but is not the correct fix. I have reposted the missing file (for Solaris users) and the fix to fpu/softfloat-native.h to isolate that file for Solaris only. Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Patch for kqemu-1.3.0pre5 on Fedora Core 4 x86_64
Troy Benjegerdes wrote: On Wed, Apr 26, 2006 at 12:50:16AM +0200, Fabrice Bellard wrote: Well, there is a change log in the archive and here it is: version 1.3.0pre6: - compile fix for Linux kernel version >= 2.6.16 - better null LDT handling (aka Plan9 and ReactOS bug) - moved monitor code to another address (aka win2k 256 MB bug) FYI, the windows 2000 install blows up right away with -kernel-kqemu on an x86_64 host with qemu-system-x86_64 . an install with kqemu-user seems to be going okay so far This is a known issue.. if you do the 1st part of the install (the blue screen text mode bit) with usermode kqemu.. then when it does its first reboot, shut down the vm and boot it up with -kernel-kemu it works fine.. Oh and of course -win2k-hack -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] gnu-c99-math.h file
--- Ben Taylor <[EMAIL PROTECTED]> a écrit : > > Apologies. That should have been isolated with a > > #ifdef __sun__ > #include "gnu-c99-math.h" > #endif > > correct. I rechecked the patch I sent to Fabrice and the gnu-c99-math.h > file is there. please make sure if you use underscores or hyphens. softfloat-native.h includes gnu-c99-math.h, but the file attached to this mail was gnu_c99_math.h Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Listen to free Music: http://www.jamendo.com Windows is proprietary, use free ReactOS instead : http://www.reactos.org ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] gnu-c99-math.h file
Sylvain Petreolle <[EMAIL PROTECTED]> wrote: > > --- Ben Taylor <[EMAIL PROTECTED]> a écrit : > > > > Apologies. That should have been isolated with a > > > > #ifdef __sun__ > > #include "gnu-c99-math.h" > > #endif > > > > correct. I rechecked the patch I sent to Fabrice and the gnu-c99-math.h > > file is there. > please make sure if you use underscores or hyphens. > softfloat-native.h includes gnu-c99-math.h, > but the file attached to this mail was gnu_c99_math.h I have no explaination. It has hypens on my source system, and on my M$ laptop. The only possible way the name changed was that the new webmail interface provided by my cable company modified the filename when I attached the diff and and gnu-c99-math.h file. But a good catch, and hopefully everyone will know to change the file name. Regards, Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Timer/clock for Linux
Paul Brook wrote: > One solution (which is also desirable for other reasons) is to > implement some form of guest cycle counting based on the > instructions actually executed. Then use that as the high-precision > timesource, and use some for of adaptive method to keep host and > guest clocks in sync. That's what I meant, expressed more clearly, except that I meant to count guest time based on the real time spent executing guest code, rather than counting individual instructions. Thanks! -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Timer/clock for Linux
On Wednesday 26 April 2006 14:01, Jamie Lokier wrote: > Paul Brook wrote: > > One solution (which is also desirable for other reasons) is to > > implement some form of guest cycle counting based on the > > instructions actually executed. Then use that as the high-precision > > timesource, and use some for of adaptive method to keep host and > > guest clocks in sync. > > That's what I meant, expressed more clearly, except that I meant to > count guest time based on the real time spent executing guest code, > rather than counting individual instructions. Thanks! How do you propose doing that? It implies you have some way of interrupting the guest after it has executed a small amount of guest code, where "small" is less than the resolution+latency of host timer interrupts. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][MIPS] Enforce aligned pc
Hi,
this patch makes qemu throw an exception when the PC is not aligned to
a word boundary.
--
Marius--- target-mips/translate.c 23 Apr 2006 15:21:24 - 1.12
+++ target-mips/translate.c 26 Apr 2006 14:02:19 -
@@ -1320,6 +1707,12 @@
uint16_t op, op1;
int16_t imm;
+ /* make sure instructions are on a word boundary */
+ if (ctx->pc & 0x3) {
+ generate_exception(ctx, EXCP_AdEL);
+ return;
+ }
+
if ((ctx->hflags & MIPS_HFLAG_BMASK) == MIPS_HFLAG_BL) {
/* Handle blikely not taken case */
MIPS_DEBUG("blikely condition (%08x)", ctx->pc + 4);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][MIPS] FPU support for MIPS
Hi All,
a new version of my FPU patch, now actually doing some math. Known
issues include, but may not be limited to:
- only support .d format, that is IEEE 64bit
- no proper float exception handling. If someone gets CONFIG_SOFTFLOAT
to compile, this should be quite easy to improve. Most of
the infrastructure required is in place.
Feedback welcome!
Cheers,
Marius
--
Marius Groeger <[EMAIL PROTECTED]>
SYSGO AG Embedded and Real-Time Software
Voice: +49 6136 9948 0 FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.comIndex: target-mips/cpu.h
===
RCS file: /sources/qemu/qemu/target-mips/cpu.h,v
retrieving revision 1.6
diff -u -u -r1.6 cpu.h
--- target-mips/cpu.h 11 Mar 2006 16:23:39 - 1.6
+++ target-mips/cpu.h 26 Apr 2006 14:02:18 -
@@ -9,10 +9,13 @@
#include "softfloat.h"
typedef union fpr_t fpr_t;
+
union fpr_t {
-double d;
-float f;
-uint32_t u[2];
+float64 fd; /* ieee double precision */
+ float32 fs; /* ieee single precision */
+int64_t d; /* binary single fixed-point */
+int32_t w; /* binary single fixed-point */
+uint32_t u32[2];
};
#if defined(MIPS_USES_R4K_TLB)
@@ -43,16 +46,48 @@
uint32_t DCR; /* ? */
#if defined(MIPS_USES_FPU)
/* Floating point registers */
-fpr_t fpr[16];
-/* Floating point special purpose registers */
+ uint32_t fpr[2*32];
+#define FPR(cpu, n, fmt) \
+ (((cpu)->CP0_Status & (1fpr[(n) & 0x1e]) : \
+ ((fpr_t*)&(cpu)->fpr[(n) & 0x1f]) \
+ )\
+ )
+
+#ifndef USE_HOST_FLOAT_REGS
+fpr_t ft0;
+fpr_t ft1;
+fpr_t ft2;
+#endif
+ float_status fp_status;
+ /* fpu implementation/revision register */
uint32_t fcr0;
-uint32_t fcr25;
-uint32_t fcr26;
-uint32_t fcr28;
-uint32_t fcsr;
+ /* fcsr */
+uint32_t fcr31;
+/* set condition, "c" must be 0 or 1 */
+#define SET_FP_COND(reg, c) do { \
+ /*assert(c == 0 || c == 1);*/ \
+ (reg) = ((reg) & ~(1<<23)) | ((c)<<23); \
+ } while(0)
+#define IS_FP_COND_SET(reg) (((reg) & (1<<23)) != 0)
+#define GET_FP_CAUSE(reg)(((reg) >> 12) & 0x3f)
+#define GET_FP_ENABLE(reg) (((reg) >> 7) & 0x1f)
+#define GET_FP_FLAGS(reg)(((reg) >> 2) & 0x1f)
+#define SET_FP_CAUSE(reg,v) do { (reg) = ((reg) & ~(0x3f << 12)) | ((v) <<
12); } while(0)
+#define SET_FP_ENABLE(reg,v) do { (reg) = ((reg) & ~(0x1f << 7)) | ((v) <<
7); } while(0)
+#define SET_FP_FLAGS(reg,v) do { (reg) = ((reg) & ~(0x1f << 2)) | ((v) <<
2); } while(0)
+#define FP_INEXACT1
+#define FP_UNDERFLOW 2
+#define FP_OVERFLOW 4
+#define FP_DIV0 8
+#define FP_INVALID16
+#define FP_UNIMPLEMENTED 32
+
#endif
#if defined(MIPS_USES_R4K_TLB)
-tlb_t tlb[16];
+tlb_t tlb[MIPS_TLB_NB];
#endif
uint32_t CP0_index;
uint32_t CP0_random;
@@ -71,6 +106,7 @@
#define CP0St_CU1 29
#define CP0St_CU0 28
#define CP0St_RP27
+#define CP0St_FR26
#define CP0St_RE25
#define CP0St_BEV 22
#define CP0St_TS21
@@ -138,9 +174,6 @@
uint32_t CP0_ErrorEPC;
uint32_t CP0_DESAVE;
/* Qemu */
-#if defined (USE_HOST_FLOAT_REGS) && defined(MIPS_USES_FPU)
-double ft0, ft1, ft2;
-#endif
struct QEMUTimer *timer; /* Internal timer */
int interrupt_request;
jmp_buf jmp_env;
Index: target-mips/exec.h
===
RCS file: /sources/qemu/qemu/target-mips/exec.h,v
retrieving revision 1.7
diff -u -u -r1.7 exec.h
--- target-mips/exec.h 11 Mar 2006 15:00:08 - 1.7
+++ target-mips/exec.h 26 Apr 2006 14:02:18 -
@@ -21,13 +21,20 @@
register host_uint_t T2 asm(AREG3);
#if defined (USE_HOST_FLOAT_REGS)
-register double FT0 asm(FREG0);
-register double FT1 asm(FREG1);
-register double FT2 asm(FREG2);
+#error "implement me."
#else
-#define FT0 (env->ft0.d)
-#define FT1 (env->ft1.d)
-#define FT2 (env->ft2.d)
+#define FDT0 (env->ft0.fd)
+#define FDT1 (env->ft1.fd)
+#define FDT2 (env->ft2.fd)
+#define FST0 (env->ft0.fs)
+#define FST1 (env->ft1.fs)
+#define FST2 (env->ft2.fs)
+#define DT0 (env->ft0.d)
+#define DT1 (env->ft1.d)
+#define DT2 (env->ft2.d)
+#define WT0 (env->ft0.w)
+#define WT1 (env->ft1.w)
+#define WT2 (env->ft2.w)
#endif
#if defined (DEBUG_OP)
@@ -65,6 +72,14 @@
void do_tlbwr (void);
void do_tlbp (void);
void do_tlbr (void);
+#ifdef MIPS_USES_FPU
+int do_cmp_d(void);
+void dump_fpu(void);
+void fpu_dump_state(CPUState *env, FILE *f,
+int (*fpu_fprintf)(FILE *f, const char *fmt, ...),
+int flags);
+#endif
+void dump_sc (void);
void do_lwl_raw (uint32_t);
void do_lwr_raw (uint32_t);
uin
[Qemu-devel] updated fpu/softfloat-native.h patch
The ammended version of fpu/softfloat-native.h patch. botched the flags when I posted it last night (no more 3am patching for me). This should be the correct fix. Ben --- softfloat-native.h.ORIG 2006-04-26 10:58:51.426224000 -0400 +++ softfloat-native.h 2006-04-26 10:59:01.255441000 -0400 @@ -7,7 +7,9 @@ #include #endif #endif +#ifdef __sun__ #include "gnu-c99-math.h" +#endif typedef float float32; typedef double float64; ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/fpu softfloat-native.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/26 15:55:55 Modified files: fpu: softfloat-native.h Log message: Remove missing include. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/fpu/softfloat-native.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text ___ 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 Branch: Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/26 16:07:35 Modified files: . : configure Log message: Solaris configure hacks. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.95&tr2=1.96&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Large USB-Patch Documentation and todays CVS patch
Hello, As Fabrice pointed out to me yesterday, it takes time to understand the new usb api. To make this process easier I have assembled a small documentation. You will find it here: http://217.20.126.200/tino/usb_api.pdf http://217.20.126.200/tino/usb_api.odg the patch which applies cleanly against todays cvs version is here, (which includes some small naming changes, as I discovered that I have used two times the same name for different functions. This was not a problem as this were local functions, but it was not so good for understanding the new api): http://217.20.126.200/tino/usb-2006-04-26.patch With kind regards, Tino H. Seifert ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Timer/clock for Linux
Paul Brook wrote: > On Wednesday 26 April 2006 14:01, Jamie Lokier wrote: > > Paul Brook wrote: > > > One solution (which is also desirable for other reasons) is to > > > implement some form of guest cycle counting based on the > > > instructions actually executed. Then use that as the high-precision > > > timesource, and use some for of adaptive method to keep host and > > > guest clocks in sync. > > > > That's what I meant, expressed more clearly, except that I meant to > > count guest time based on the real time spent executing guest code, > > rather than counting individual instructions. Thanks! > > How do you propose doing that? It implies you have some way of interrupting > the guest after it has executed a small amount of guest code, where "small" > is less than the resolution+latency of host timer interrupts. Hmm. I hadn't thought that through, but it still works. It doesn't matter if the guest runs, say, for 20ms before its next emulated 1kHz interrupt - so long as it's not dependent on values from the emulated timer chip after 1ms (or any other emulated device which reveals the time). If the guest does read a device which depends on the time, that's an opportunity to interrupt it. Otherwise, from the guest's view, it's just as if the emulated CPU got faster for a while with the interrupts perfectly timed. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu, kqemu-1.3.0pre6 & freebsd
First, thanks to Fabrice for releasing a new kqemu and Juergen Lock for a prompt freebsd port update! I did some testing and have the following to report: The good news: - plan 9 works with kernel-kqemu and user-kqemu. - user mode time in user/kernel kqemu mode is 1/3 of -no-kqemu case for plan 9 (I used "mk clean all" in /sys/src/9/pc dir as a benchmark). Not so good news: - compared to freebsd and other guests where we get over 10 times performance improvement for usermode code, plan9 only gets about 3 times. - elapsed time in user-kqemu is 2/3 of -no-kqemu for plan 9. - elapsed time in kernel-kqemu is *six* times that of -no-kqemu. system time in kernel-kqemu mode is *11* times that of -no-kqemu. Bad news: - FreeBSD4 guest image dies during boot in init when user/kernel kqemu is used. It works in -no-kqemu mode as before. - mouse scrolling is broken. The mouse seems to think it is at a boundary while still in the middle of the qemu window. You have to scroll it in the opposite direction beyond the qemu window boundary to fix this. Win2k seems to work about as well as before (which is pretty darn good!). I wonder if the qemu port needs to be updated -- does the new kqemu depend on changes made in qemu since 4/14 (the date of freebsd port of qemu)? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] qemu/fpu softfloat-native.h
please revert this. Ben Taylor posted the correct fix on the list and the missing include file. --- Paul Brook <[EMAIL PROTECTED]> a écrit : > CVSROOT: /sources/qemu > Module name: qemu > Branch: > Changes by: Paul Brook <[EMAIL PROTECTED]> 06/04/26 15:55:55 > > Modified files: > fpu: softfloat-native.h > > Log message: > Remove missing include. > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/fpu/softfloat-native.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Listen to free Music: http://www.jamendo.com Windows is proprietary, use free ReactOS instead : http://www.reactos.org ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/fpu softfloat-native.h
On Wednesday 26 April 2006 19:30, Sylvain Petreolle wrote: > please revert this. > Ben Taylor posted the correct fix on the list and the missing include file. The patch posted was not correct (the #ifdef is redundant with the one inside the include file), and wasn't sufficient to make qemu work on my Solaris systems either. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Where is this change coming from?
Compile environment - Solaris 9/Ultra 10 workstation
this is code generated by a 0.7.2-solaris port of dyngen for i386-softmmu/op.h
for the function
case INDEX_op_imulb_AL_T0: {
extern void op_imulb_AL_T0();
extern char __dot_umul __asm__(".umul");
memcpy(gen_code_ptr, (void *)((char *)&op_imulb_AL_T0+4), 76);
*(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16)) &
~0x3fff) | (long)(&__dot_umul) + 0) - (long)(gen_code_ptr + 16))>>2)
& 0x3fff);
gen_code_ptr += 76;
}
break;
this is the function generated by the 0.8.0-cvs code
case INDEX_op_imulb_AL_T0: {
extern void op_imulb_AL_T0();
extern char __dot_umul __asm__(".umul");
memcpy(gen_code_ptr, (void *)((char *)&op_imulb_AL_T0+4), 76);
*(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16)) &
~0x3fff) | (lo + 0) - (long)(gen_code_ptr + 16))>>2)
& 0x3fff);
gen_code_ptr += 76;
}
break;
This is the compile sequence for the 0.8.0-cvs with the error message:
gcc -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g2 -ffixed-g3 -I. -I..
-I/export/src/qemu/qemu-solaris-9/target-i386 -I/export/src/qemu/qemu-solaris-9
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I/export/src/qemu/qemu-solaris-9/fpu -DHAS_AUDIO
-I/export/src/qemu/qemu-solaris-9/slirp -c -o translate-op.o
/export/src/qemu/qemu-solaris-9/translate-op.c
In file included from /export/src/qemu/qemu-solaris-9/translate-op.c:36:
./op.h: In function `dyngen_code':
./op.h:896: error: `lo' undeclared (first use in this function)
./op.h:896: error: (Each undeclared identifier is reported only once
./op.h:896: error: for each function it appears in.)
./op.h:896: error: syntax error before ';' token
./op.h:904: error: `op_cmpneqsd' undeclared (first use in this function)
./op.h:905: error: `param1' undeclared (first use in this function)
./op.h:906: error: `param2' undeclared (first use in this function)
./op.h:894: warning: unused variable `__dot_umul'
looking carefully between the two generated functions, I see that they are
slightly
different. The first one (0.7.2) compiles cleanly and runs. The second one
(0.8.0-cvs)
does not compiile cleanly, and it appears that the function call has been
left off the line of code.
*(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16)) &
~0x3fff) | (long)(&__dot_umul) + 0) - (long)(gen_code_ptr + 16))>>2)
& 0x3fff);
*(uint32_t *)(gen_code_ptr + 16) = ((*(uint32_t *)(gen_code_ptr + 16)) &
~0x3fff) | (lo + 0) - (long)(gen_code_ptr + 16))>>2)
The specific difference in the working copy has
(long)(&__dot_umul) + 0)
while the compile failling copy has
(lo + 0)
Am I missing something? There are many cascading errors due to "lo not defined"
in this environment, and I'm not really sure if it's a bug, or some problem in
my
environment.
Ideas?
Thanks,
Ben
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu hw/sun4u.c hw/sun4m.c ./vl.h ./loader.c ./...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/26 22:05:26 Modified files: hw : sun4u.c sun4m.c . : vl.h loader.c elf_ops.h Log message: added entry parameter to ELF loader CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4u.c.diff?tr1=1.7&tr2=1.8&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/sun4m.c.diff?tr1=1.15&tr2=1.16&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.111&tr2=1.112&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/loader.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/elf_ops.h.diff?tr1=1.1&tr2=1.2&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw mips_r4k.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/26 22:06:56 Modified files: hw : mips_r4k.c Log message: ELF loader (Thiemo Seufer) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/mips_r4k.c.diff?tr1=1.14&tr2=1.15&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] Enforce aligned pc
Is it possible that the pc gets unaligned ? Fabrice. Marius Groeger wrote: Hi, this patch makes qemu throw an exception when the PC is not aligned to a word boundary. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] FPU support for MIPS
A few remarks: 1) Why do you use 3 temporaries ? Maybe two suffice in most cases. 2) do_cmp_d() should be completely decoded at translation time. 3) I suspect the macro FPR() does too many things at runtime which gives an important performance loss. CP0St_FR should be known at translation time. You should use CONFIG_SOFTFLOAT to validate your code. The ARM target does it, so it works (see the configure script). Fabrice. Marius Groeger wrote: Hi All, a new version of my FPU patch, now actually doing some math. Known issues include, but may not be limited to: - only support .d format, that is IEEE 64bit - no proper float exception handling. If someone gets CONFIG_SOFTFLOAT to compile, this should be quite easy to improve. Most of the infrastructure required is in place. Feedback welcome! Cheers, Marius ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch
> As Fabrice pointed out to me yesterday, it takes time to understand the > new usb api. To make this process easier I have assembled a small > documentation. > You will find it here: > http://217.20.126.200/tino/usb_api.pdf > http://217.20.126.200/tino/usb_api.odg That is a nice description. > the patch which applies cleanly against todays cvs version is here, > (which includes some small naming changes, as I discovered that I have > used two times the same name for different functions. This was not a > problem as this were local functions, but it was not so good for > understanding the new api): > http://217.20.126.200/tino/usb-2006-04-26.patch I am quite sure you put a lot of work into this patch, but you sure make it hard to appreciate, too. First note that applying such a huge patch is bad. Let me help you (a little more than last time) to understand that: You are almost guaranteed to introduce bugs, and what's worse, regressions. Because it is so huge, you are further guaranteed to have a real hard time tracking that regression. Also, you make it really, really awkward to pick the changes which are unquestionable, and skip the questionable ones. For example, your patch "fixes" a few white spaces. This does not hurt, but has no meaning either, and slows down patch reading. Also, you rename some things when it has no apparent use to rename them, such as usb_device_add, or product_name. Parts of the patch are plainly unreadable, because you move code around. I suppose you not only moved them around, but made subtle changes -- hard-to-notice-because-moved changes. As of now, no files in CVS that I am aware of contain "chagelog" lines. However, these reveal that you made changes as early as 20th April of 2005? Plenty of time feeding small patches since then ;-) Continuing with comments: you change the comment "QEMU USB HUB emulation" in usb-hub.c to "QEMU PC System Emulator" and backdate Fabrice's copyright from 2005 to 2003-2004? Why? In the patch, you made plenty of white-space changes which make it very difficult to spot real changes. Again, I think you did some very valuable work. However, I'd be so much happier if you split the patch up into meaningful patches, not a rollup which is hard to understand *and* huge. I now spent about one hour trying to understand your fixes, and I know almost as much as when I started about your fixes. Hope this helps, Dscho -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH][MIPS] Enforce aligned pc
Fabrice Bellard wrote: > Is it possible that the pc gets unaligned ? Yes, e.g. due to stack corruption which overwrites the return address. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch
Hello Johannes, Thanks for your comments. Johannes Schindelin wrote: > I am quite sure you put a lot of work into this patch, but you sure make it > hard to appreciate, too. > > First note that applying such a huge patch is bad. Let me help you (a little > more than last time) Sorry I dont know why, but I have no other message from you in my Inbox, so I can't tell what you have written last time. > to understand that: You are almost guaranteed to > introduce bugs, and what's worse, regressions. Because it is so huge, you > are further guaranteed to have a real hard time tracking that regression. > I agree with you on that. But I have a reason for doing it and I have no one heard complaining, this or that has been broken, which worked before. On the other side, I can say for sure, that with that patch a lot more things do work. So even if something may be broken and cvs changes will with great probability break things (see softfloat-native.h today), it does not mean the patch is bad. The only question which has to be asked is, could it be done with smaller patches. And on that point I disagree with you. I claim that it could not be done. > Also, you make it really, really awkward to pick the changes which are > unquestionable, and skip the questionable ones. > > For example, your patch "fixes" a few white spaces. This does not hurt, but > has no meaning either, and slows down patch reading. > Also, you rename some things when it has no apparent use to rename them, > such as usb_device_add, or product_name. > Sorry but on that point you say things which are in no case provable by any study. The contrary is true, good readable code, many comments, good structered function names, which follow a pattern, help to write good and error free code. When I got my hands on the usb code, there were as many as almost none comments. I needed more than one hour to even get a glue what is going on in usb.h (which is apparently not the reason for having header files). The usb code as I obtained it, was in a state which you can describe in the words "quick and dirty". If you find such conditions you have to change without mercy. If you don't do it and the person, which has applied the first changes to cvs, has done a quick and dirty job, you will always have a patch work software, without any structure and without any consistent interface. So maybe that the person, who wants to commit the patch to cvs, has more work to do. But this persons work is absolutly nonrelevant in compare to the many people who will read the (then better) code, and understand it faster and deeper. I'm absolutly sure, that you will find examples where I have not choosen the best solution, but if I would look into any code which you have written the same would be valid and that is not a problem as long as the changes which are good outweigh the bad ones. > Parts of the patch are plainly unreadable, because you move code around. I > suppose you not only moved them around, but made subtle changes -- > hard-to-notice-because-moved changes. > > As of now, no files in CVS that I am aware of contain "chagelog" lines. Until the 19th century it was not common that a doctor has washed his hands when he had evaluated a patient. This doesn't mean it is a bad idea to do so. My experiences with other projects have shown, that it is in most cases a good idea to have these changelog lines even if you use cvs. But if the majority of the people here is against them, I will take them out - that is not a problem. It is sometimes not so easy to find the person who had developed a portion of source code after lets say 5 years. In the cvs you will normaly find only the person who has applied the patch and not the person who has developed the code. If you then want to contact the original developer it can be a hard job to find him. So thats the reason for making these short changelog lines. Some opensource licenses (not the one for qemu) even require such changelog lines and I personaly believe, it is good to have them. > However, these reveal that you made changes as early as 20th April of 2005? > Plenty of time feeding small patches since then ;-) > > Continuing with comments: you change the comment "QEMU USB HUB emulation" in > usb-hub.c to "QEMU PC System Emulator" and backdate Fabrice's copyright from > 2005 to 2003-2004? Why? > Yes sorry about that, it was not my intention to do so. Let me explain how that was happening. As you may have noticed, Fabrice has added usb-hub.c earlier this week, after I had already submitted my patch. As I had updated my local cvs version this changes were rejected. And for one or the other reason I had not noticed, the difference in the comment. I haved changed it now. > In the patch, you made plenty of white-space changes which make it very > difficult to spot real changes. > > Again, I think you did some very valuable work. However, I'd be so much > happier if you split the patch up into meaningful patches, not a rollup > w
[Qemu-devel] Re: [PATCH] Don't install HTML if its not generated
I included a context diff this time to make it easier to see the problem. Chris --- Makefile23 Apr 2006 17:57:59 - 1.97 +++ Makefile27 Apr 2006 02:09:07 - @@ -56,7 +56,9 @@ $(INSTALL) -m 644 $(SRC_PATH)/pc-bios/$$x "$(DESTDIR)$(datadir)"; \ done +ifdef BUILD_DOCS mkdir -p "$(DESTDIR)$(docdir)" $(INSTALL) -m 644 qemu-doc.html qemu-tech.html "$(DESTDIR)$(docdir)" +endif ifndef CONFIG_WIN32 mkdir -p "$(DESTDIR)$(mandir)/man1" $(INSTALL) qemu.1 qemu-img.1 "$(DESTDIR)$(mandir)/man1" ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Large USB-Patch Documentation and todays CVS patch
Johannes Schindelin wrote: I am quite sure you put a lot of work into this patch, but you sure make it hard to appreciate, too. First note that applying such a huge patch is bad. Let me help you (a little more than last time) to understand that: You are almost guaranteed to introduce bugs, and what's worse, regressions. Because it is so huge, you are further guaranteed to have a real hard time tracking that regression. Seeing as there is a release coming up this is most definitely not a good thing. Initial testing yielded lots of this. I'd like to see my all-in-one patch stripped out. Then simply modifying the linux redirector to support the improved error handling (have it clear endpoint halt/etc) and other improvements. Later, the new redirectors can be merged in and modified as necessary. The purpose of modifying the user interface to the usb layer also confuses me. What was the reasoning behind changing host:busaddr.addr to host:busaddr:addr and host:VID:PID to host:VIDxPID? This is something that should be abstracted in the layer and not handed down to the user. Why display the bcdUSB revision and not the connected speed to the user (as is already done)? To argue that this must all go in at once or none at all is silly. I've seen the changes and know that my redirectors aren't necessary for this to function. I'm not trying to get anyone down on this but am just saying this needs more discussion and thought. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
