Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Tony Nelson]

At 2:37 PM +0100 3/17/07, Thomas Orgis wrote:
>I'd like to add that with qemu 0.9.0 release it's the same problem,
>that somehow seems to recurr from time to time (seen old similar
>reports with older qemu release(s)) in helper.c.
>
>We at SourceMage GNU/Linux got reports of failed builds with that error
>that are apparently fixed by reducing -march cflag to pentium-mmx as
>opposed to pentium2,3,4 or pentium-m as well as any athlon.
>Any sse flags also seem to trigger this error.
>qemu 0.8.6 built without probs with -march=pentium-m, for example (we
>still use the same compiler gcc-3.4.6 for this).
 ...

Could this be caused by having a 586 kernel installed?  There's a bug in
FC6 anaconda that causes it to sometimes install the 586 kernel when it
should have installed the 686 kernel.  The fix is to install the 686 kernel.
-- 

TonyN.:'   
  '  


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu Changelog Makefile.target vl.c vl.h hw/mip...

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/18 00:30:29

Modified files:
.  : Changelog Makefile.target vl.c vl.h 
hw : mips_malta.c mips_r4k.c 
target-mips: cpu.h mips-defs.h translate.c 
Added files:
target-mips: translate_init.c 

Log message:
MIPS -cpu selection support, by Herve Poussineau.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemu&r1=1.132&r2=1.133
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.148&r2=1.149
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.265&r2=1.266
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemu&r1=1.193&r2=1.194
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.15&r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.38&r2=1.39
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.23&r2=1.24
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemu&r1=1.7&r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.36&r2=1.37
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemu&rev=1.1


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

[Paul Brook]

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


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] PXA-specific ARM hacks.

[andrzej zaborowski]

On 17/03/07, andrzej zaborowski <[EMAIL PROTECTED]> wrote:

On 17/03/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> On Friday 16 March 2007 22:06, andrzej zaborowski wrote:
> > This patch contains some ugly but very useful chnages:
> >  - in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other
> > architectures.
>
> This is ok. Though I'd prefer it to actually be common code (like
> CPU_INTERRUPT_DEBUG).
>
> >  - wake the cpu up on CPU_INTERRUPT_EXITTB - this serves waking the
> > CPU up without asserting IRQ or FIQ, which is possible on PXA. Would
> > it be better to add a separate interrupt type instead?
>
> I think this is probably ok. Could do with a comment somewhere saying so.
>
> >  - in target-arm/translate.c, don't terminate the TB after a CP15
> > write. The purpose of this is to imitate the real processor's
> > instruction cache (to some degree). OSes should never need rely on the
> > cache prefetch but unfortunately Linux for pxa does when it's waking
> > up from sleep or deep idle, when enabling the MMU (simplifies things a
> > lot for Linux).
>
> This is not acceptable in its current form. IIRC on arm cores the effects take
> effect once all insn have worked through the pipeline (typically a few
> cycles), and I bet there's code that relies on this. ie:
> mcr cp15, ...;nop;nop;nop;nop;@expect cp15 write to have taken effect by now
>
> A more acceptable solution would be:
> - Only extend the TB for the specific instruction that linux abuses
> - Limit the number of instructions that can follow before the end of the TB.
> - Add a comment saying what this hack is for.

Ok. Attaching a second version of this patch. The number of
instructions after MMU enable and before TB ends is limited by the
obligatory CPWAIT rather than in qemu.


Oops, one more try. This time removing the use of cpu_reset() on
entering Standby because cpu_reset() now does more than we want.

Andrzej
From 8d4d84ee71048638fd101ed27ba37b038ddf4651 Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski <[EMAIL PROTECTED]>
Date: Sat, 17 Mar 2007 22:13:29 +0100
Subject: [PATCH] PXA-specific ARM hacks.

---
 cpu-all.h  |3 ++-
 cpu-exec.c |   20 +++-
 hw/pxa2xx.c|3 ++-
 target-arm/translate.c |   11 ---
 4 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 9b617fc..177bcba 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -763,7 +763,8 @@ void cpu_dump_statistics (CPUState *env, FILE *f,
   int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
   int flags);
 
-void cpu_abort(CPUState *env, const char *fmt, ...);
+void cpu_abort(CPUState *env, const char *fmt, ...)
+__attribute__ ((__format__ (__printf__, 2, 3)));
 extern CPUState *first_cpu;
 extern CPUState *cpu_single_env;
 extern int code_copy_enabled;
diff --git a/cpu-exec.c b/cpu-exec.c
index 48c2a93..10e2f2b 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -275,9 +275,10 @@ int cpu_exec(CPUState *env1)
 #elif defined(TARGET_ARM)
 if (env1->halted) {
 /* An interrupt wakes the CPU even if the I and F CPSR bits are
-   set.  */
-if (env1->interrupt_request
-& (CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD)) {
+   set.  We use EXITTB to silently wake CPU without causing an
+   actual interrupt.  */
+if (env1->interrupt_request &
+(CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD | CPU_INTERRUPT_EXITTB)) {
 env1->halted = 0;
 } else {
 return EXCP_HALTED;
@@ -414,6 +415,12 @@ int cpu_exec(CPUState *env1)
 env->exception_index = EXCP_DEBUG;
 cpu_loop_exit();
 }
+if (interrupt_request & CPU_INTERRUPT_HALT) {
+env->interrupt_request &= ~CPU_INTERRUPT_HALT;
+env->halted = 1;
+env->exception_index = EXCP_HLT;
+cpu_loop_exit();
+}
 #if defined(TARGET_I386)
 if ((interrupt_request & CPU_INTERRUPT_SMI) &&
 !(env->hflags & HF_SMM_MASK)) {
@@ -511,12 +518,7 @@ int cpu_exec(CPUState *env1)
} else if (interrupt_request & CPU_INTERRUPT_TIMER) {
//do_interrupt(0, 0, 0, 0, 0);
env->interrupt_request &= ~CPU_INTERRUPT_TIMER;
-   } else if (interrupt_request & CPU_INTERRUPT_HALT) {
-   env->interrupt_request &= ~CPU_INTERRUPT_HALT;
-   env->halted = 1;
-   env->exception_index = EXCP_HLT;
-   cpu_loop_exit();
-}
+   }
 #elif defined(TARGET_ARM)
 if (interrupt_request & CPU_INTERRUPT_FIQ
 && !(env->uncached_cpsr & CPSR_F)) {
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index c8c6eb4..2d

Re: [Qemu-devel] [PATCH] PXA-specific ARM hacks.

[andrzej zaborowski]

On 17/03/07, Paul Brook <[EMAIL PROTECTED]> wrote:

On Friday 16 March 2007 22:06, andrzej zaborowski wrote:
> This patch contains some ugly but very useful chnages:
>  - in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other
> architectures.

This is ok. Though I'd prefer it to actually be common code (like
CPU_INTERRUPT_DEBUG).

>  - wake the cpu up on CPU_INTERRUPT_EXITTB - this serves waking the
> CPU up without asserting IRQ or FIQ, which is possible on PXA. Would
> it be better to add a separate interrupt type instead?

I think this is probably ok. Could do with a comment somewhere saying so.

>  - in target-arm/translate.c, don't terminate the TB after a CP15
> write. The purpose of this is to imitate the real processor's
> instruction cache (to some degree). OSes should never need rely on the
> cache prefetch but unfortunately Linux for pxa does when it's waking
> up from sleep or deep idle, when enabling the MMU (simplifies things a
> lot for Linux).

This is not acceptable in its current form. IIRC on arm cores the effects take
effect once all insn have worked through the pipeline (typically a few
cycles), and I bet there's code that relies on this. ie:
mcr cp15, ...;nop;nop;nop;nop;@expect cp15 write to have taken effect by now

A more acceptable solution would be:
- Only extend the TB for the specific instruction that linux abuses
- Limit the number of instructions that can follow before the end of the TB.
- Add a comment saying what this hack is for.


Ok. Attaching a second version of this patch. The number of
instructions after MMU enable and before TB ends is limited by the
obligatory CPWAIT rather than in qemu.

Regards,
Andrzej
From 37336004f611f544fc7d2eb763445fdca3109cdf Mon Sep 17 00:00:00 2001
From: Andrzej Zaborowski <[EMAIL PROTECTED]>
Date: Sat, 17 Mar 2007 21:26:12 +0100
Subject: [PATCH] PXA-specific ARM hacks.

---
 cpu-all.h  |3 ++-
 cpu-exec.c |   20 +++-
 target-arm/translate.c |7 ++-
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 9b617fc..177bcba 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -763,7 +763,8 @@ void cpu_dump_statistics (CPUState *env, FILE *f,
   int (*cpu_fprintf)(FILE *f, const char *fmt, ...),
   int flags);
 
-void cpu_abort(CPUState *env, const char *fmt, ...);
+void cpu_abort(CPUState *env, const char *fmt, ...)
+__attribute__ ((__format__ (__printf__, 2, 3)));
 extern CPUState *first_cpu;
 extern CPUState *cpu_single_env;
 extern int code_copy_enabled;
diff --git a/cpu-exec.c b/cpu-exec.c
index 48c2a93..10e2f2b 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -275,9 +275,10 @@ int cpu_exec(CPUState *env1)
 #elif defined(TARGET_ARM)
 if (env1->halted) {
 /* An interrupt wakes the CPU even if the I and F CPSR bits are
-   set.  */
-if (env1->interrupt_request
-& (CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD)) {
+   set.  We use EXITTB to silently wake CPU without causing an
+   actual interrupt.  */
+if (env1->interrupt_request &
+(CPU_INTERRUPT_FIQ | CPU_INTERRUPT_HARD | CPU_INTERRUPT_EXITTB)) {
 env1->halted = 0;
 } else {
 return EXCP_HALTED;
@@ -414,6 +415,12 @@ int cpu_exec(CPUState *env1)
 env->exception_index = EXCP_DEBUG;
 cpu_loop_exit();
 }
+if (interrupt_request & CPU_INTERRUPT_HALT) {
+env->interrupt_request &= ~CPU_INTERRUPT_HALT;
+env->halted = 1;
+env->exception_index = EXCP_HLT;
+cpu_loop_exit();
+}
 #if defined(TARGET_I386)
 if ((interrupt_request & CPU_INTERRUPT_SMI) &&
 !(env->hflags & HF_SMM_MASK)) {
@@ -511,12 +518,7 @@ int cpu_exec(CPUState *env1)
} else if (interrupt_request & CPU_INTERRUPT_TIMER) {
//do_interrupt(0, 0, 0, 0, 0);
env->interrupt_request &= ~CPU_INTERRUPT_TIMER;
-   } else if (interrupt_request & CPU_INTERRUPT_HALT) {
-   env->interrupt_request &= ~CPU_INTERRUPT_HALT;
-   env->halted = 1;
-   env->exception_index = EXCP_HLT;
-   cpu_loop_exit();
-}
+   }
 #elif defined(TARGET_ARM)
 if (interrupt_request & CPU_INTERRUPT_FIQ
 && !(env->uncached_cpsr & CPSR_F)) {
diff --git a/target-arm/translate.c b/target-arm/translate.c
index cd1c04d..885637c 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -1605,8 +1605,13 @@ static int disas_cp15_insn(DisasContext *s, uint32_t 
insn)
 } else {
 gen_movl_T0_reg(s, rd);
 gen_op_movl_cp15_T0(insn);
+/* Nor

[Qemu-devel] KQEMU Darwin port status?

[Philip Boulain]

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


Thanks,
LionsPhil
1. http://developer.apple.com/documentation/Darwin/Conceptual/ 
KernelProgramming/boundaries/chapter_14_section_6.html




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

[Stefan Weil]

Thiemo Seufer wrote
> Stefan Weil 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.
>> The current solution (1) is not good, because users get crashes
>> and don't know the reason, and experienced users spend a lot of
>> time with debugging (at least I did).
>>
>> Solution (2) is needed to run existing binary code.
>>
>> Solution (3) is the minimum I expect of an emulation like QEMU.
>>
>> I prefer a mix of solutions (2) and (3): display a message and
>> try to emulate the original behaviour.
>>
>> Do you agree, and would you accept patches which implement this?
> If the AR7 CPU spec defines the semantics of branch delay slots more
> precisely than the architecture spec then I'll consider a patch.
AR7 claims to use a 4KEc CPU, so there is only the official
spec from MIPS.
> If this isn't the case then I ask you to use a non-broken compiler/
> assembly code.
What about closed source binary code (firmware in my case)?
Of course it can be patched, but this is more work than implementing
(2) and (3) in QEMU.

Stefan



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] Fix guest x86/amd64 helper_fprem/helper_fprem1

[Julian Seward]

The helpers for x86/amd64 fprem and fprem1 in target-i386/helper.c are
significantly borked and, for example, cause konqueror in RedHat8 (x86
guest) to go into an infinite loop when displaying http://news.bbc.co.uk.

helper_fprem has the following borkage:
- various Inf/Nan/zero inputs not handled correctly
- incorrect rounding when converting negative 'dblq' to 'q'
- incorrect order of assignment to C bits (0,3,1 not 0,1,3)

helper_fprem1 has those problems and is also incorrect about the points
at which its rounding needs to differ from that of helper_fprem.

Patch below fixes all these.  It brings the fprem and fprem1 behaviour 
very much closer to the hardware -- not identical, but close.  Some
+0.0 results should really be -0.0 and there may still be other differences.

Anyway konquerer no longer loops with the patch applied.

J
--- ../Orig/qemu-0.9.0/target-i386/helper.c	2007-02-05 23:01:54.0 +
+++ target-i386/helper.c	2007-03-17 17:21:02.0 +
@@ -3097,30 +3097,51 @@
 CPU86_LDouble dblq, fpsrcop, fptemp;
 CPU86_LDoubleU fpsrcop1, fptemp1;
 int expdif;
-int q;
+signed long long int q;
+
+if (isinf(ST0) || isnan(ST0) || isnan(ST1) || (ST1 == 0.0)) {
+   ST0 = 0.0 / 0.0; /* NaN */
+   env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
+   return;
+}
 
 fpsrcop = ST0;
 fptemp = ST1;
 fpsrcop1.d = fpsrcop;
 fptemp1.d = fptemp;
 expdif = EXPD(fpsrcop1) - EXPD(fptemp1);
+
+if (expdif < 0) {
+/* optimisation? taken from the AMD docs */
+env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
+/* ST0 is unchanged */
+	return;
+}
+
 if (expdif < 53) {
 dblq = fpsrcop / fptemp;
-dblq = (dblq < 0.0)? ceil(dblq): floor(dblq);
+	/* round dblq towards nearest integer */
+dblq = rint(dblq);
 ST0 = fpsrcop - fptemp*dblq;
-q = (int)dblq; /* cutting off top bits is assumed here */
+
+	/* convert dblq to q by truncating towards zero */
+	if (dblq < 0.0)
+   q = (signed long long int)(-dblq);
+else
+   q = (signed long long int)dblq;
+
 env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
-/* (C0,C1,C3) <-- (q2,q1,q0) */
-env->fpus |= (q&0x4) << 6; /* (C0) <-- q2 */
-env->fpus |= (q&0x2) << 8; /* (C1) <-- q1 */
-env->fpus |= (q&0x1) << 14; /* (C3) <-- q0 */
+/* (C0,C3,C1) <-- (q2,q1,q0) */
+env->fpus |= (q&0x4) << (8-2);  /* (C0) <-- q2 */
+env->fpus |= (q&0x2) << (14-1); /* (C3) <-- q1 */
+env->fpus |= (q&0x1) << (9-0);  /* (C1) <-- q0 */
 } else {
 env->fpus |= 0x400;  /* C2 <-- 1 */
 fptemp = pow(2.0, expdif-50);
 fpsrcop = (ST0 / ST1) / fptemp;
-/* fpsrcop = integer obtained by rounding to the nearest */
-fpsrcop = (fpsrcop-floor(fpsrcop) < ceil(fpsrcop)-fpsrcop)?
-floor(fpsrcop): ceil(fpsrcop);
+/* fpsrcop = integer obtained by chopping */
+fpsrcop = (fpsrcop < 0.0)?
+-(floor(fabs(fpsrcop))): floor(fpsrcop);
 ST0 -= (ST1 * fpsrcop * fptemp);
 }
 }
@@ -3130,26 +3151,48 @@
 CPU86_LDouble dblq, fpsrcop, fptemp;
 CPU86_LDoubleU fpsrcop1, fptemp1;
 int expdif;
-int q;
-
-fpsrcop = ST0;
-fptemp = ST1;
+signed long long int q;
+
+if (isinf(ST0) || isnan(ST0) || isnan(ST1) || (ST1 == 0.0)) {
+   ST0 = 0.0 / 0.0; /* NaN */
+   env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
+   return;
+}
+
+fpsrcop = (CPU86_LDouble)ST0;
+fptemp = (CPU86_LDouble)ST1;
 fpsrcop1.d = fpsrcop;
 fptemp1.d = fptemp;
 expdif = EXPD(fpsrcop1) - EXPD(fptemp1);
+
+if (expdif < 0) {
+/* optimisation? taken from the AMD docs */
+env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
+	/* ST0 is unchanged */
+return;
+}
+
 if ( expdif < 53 ) {
-dblq = fpsrcop / fptemp;
+dblq = fpsrcop/*ST0*/ / fptemp/*ST1*/;
+	/* round dblq towards zero */
 dblq = (dblq < 0.0)? ceil(dblq): floor(dblq);
-ST0 = fpsrcop - fptemp*dblq;
-q = (int)dblq; /* cutting off top bits is assumed here */
+ST0 = fpsrcop/*ST0*/ - fptemp*dblq;
+
+	/* convert dblq to q by truncating towards zero */
+	if (dblq < 0.0)
+   q = (signed long long int)(-dblq);
+else
+   q = (signed long long int)dblq;
+
 env->fpus &= (~0x4700); /* (C3,C2,C1,C0) <--  */
-/* (C0,C1,C3) <-- (q2,q1,q0) */
-env->fpus |= (q&0x4) << 6; /* (C0) <-- q2 */
-env->fpus |= (q&0x2) << 8; /* (C1) <-- q1 */
-env->fpus |= (q&0x1) << 14; /* (C3) <-- q0 */
+/* (C0,C3,C1) <-- (q2,q1,q0) */
+env->fpus |= (q&0x4) << (8-2);  /* (C0) <-- q2 */
+env->fpus |= (q&0x2) << (14-1); /* (C3) <-- q1 */
+env->fpus |= (q&0x1) << (9-0);  /* (C1) <-- q0 */
 } else {
+int N = 32 + (expdif % 32); /* a

[Qemu-devel] qemu/hw ppc_chrp.c ppc_prep.c realview.c usb-oh...

[Paul Brook]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook  07/03/17 16:59:31

Modified files:
hw : ppc_chrp.c ppc_prep.c realview.c usb-ohci.c 
 usb.h versatilepb.c 

Log message:
OHCI USB PXA support (Andrzej Zaborowski).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_chrp.c?cvsroot=qemu&r1=1.27&r2=1.28
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc_prep.c?cvsroot=qemu&r1=1.30&r2=1.31
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/realview.c?cvsroot=qemu&r1=1.5&r2=1.6
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-ohci.c?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb.h?cvsroot=qemu&r1=1.11&r2=1.12
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/versatilepb.c?cvsroot=qemu&r1=1.10&r2=1.11


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0 .9.0 reproducible

[herbie hancock]

> -Ursprüngliche Nachricht-
> Von: qemu-devel@nongnu.org
> Gesendet: 16.03.07 13:11:15
> An: qemu-devel@nongnu.org
> Betreff: Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 
> reproducible


> herbie hancock wrote:
> > Hello, i had also a reproducible disk crash:
> > info of the last good image, size is about 3,5GB
> > 
> > I never experienced such a bad problem with qemu before, maybe it is a 
> > problem with qcow2 format ?
> 
> After the problems with qcow2 images which I reported here a few weeks
> ago, I've only been using qcow images (under QEMU 0.9.0), without such
> surprises.  So it seems qemu has some bug related to qcow2 images,
> maybe manifesting itself only after they get larger than 4GB...
> 
> 
> Best regards
>   J Esteves
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

I am quite sure now that it is a problem with the qcow2 format. 
I can reprodue the bug only on a qcow2 image. I did a disk fill test with dd on 
a qcow2 Image and the same test on a qcow Image, 
both images had  the same content. (Image 16GB Debian 4.0 Etch, hda1 ext3 15 
gb,  hda5 swap 700MB)

The qcow2 Image was totally corrupted and is not bootable any more, the qcow 
Image passed the tests without any errors
Host system was now winxp sp2  instead of win2k, so i dont think its a problem 
of the host os.

I think a big  warning for the users is necessary that they should work with 
qcow instead of qcow2 until the bug is fixed

Best regards
hr

Test Setup:
---
Made a copy of the last known good qcow2 image (size 3.3 GB) and converted it 
to qcow

..\QemuManager\qemu\qemu-img.exe convert debian4_0.dsk -O qcow 
debian4_0_qcow.dsk

Crashtest with debian4_0.dsk (qcow2 format)
---

Size of intact debian4_0.dsk 3.551.580.160 Bytes

file format: qcow2
virtual size: 16G (16777216000 bytes)
disk size: 3.3G
cluster_size: 4096
Snapshot list:
IDTAG VM SIZEDATE   VM CLOCK
1 test79M 2007-03-11 18:34:49   00:07:47.475


Start VM: I:\debian4.0\QemuManager\qemu\qemu.exe -L 
"I:\debian4.0\QemuManager\qemu" -m 256 -hda 
"I:\debian4.0\debian4\debian4_0.dsk" -cdrom 
"I:\debian4.0\debian4\debian-testing-i386-DVD-1.iso" -kernel-kqemu -net 
nic,vlan=0 -net user,vlan=0 -std-vga -localtime

fsck on mounted filesystem: fsck -nv /dev/hda1 show no errors except # of free 
inodes
df 19% of system used (Total: 15409468 used: 2641020)
fill the rest of the disk: dd if=/dev/zero of=/tmp/bigfile bs=16M
dd stops with disk full, ok
---> now fsck -nv /dev/hda1 shows endless output of errors<-ERROR
rm bigfile
shutdown system did work

---> Restart VM: Fatal not a bootable harddisk ext3 is totally corrupt
<---  ERROR

In this case there was no crash on the VM, as i had on WIN2K, header of the 
image file seems to be still intact

Info after crash:
image: debian4_0.dsk
file format: qcow2
virtual size: 16G (16777216000 bytes)
disk size: 16G < 16GB (why so much on a 15GB Partition ?)
cluster_size: 4096
Snapshot list:
IDTAG VM SIZEDATE   VM CLOCK
1 test79M 2007-03-11 18:34:49   00:07:47.475

Size of crashed debian4_0.dsk 16.659.554.304 Bytes



Test with debian4_0_qcow.dsk:
--

Size of debian4_0_qcow.dsk: 3.105.832.960 Bytes

image: debian4_0_qcow.dsk
file format: qcow
virtual size: 16G (16777216000 bytes)
disk size: 2.9G
cluster_size: 4096

Start VM: I:\debian4.0\QemuManager\qemu\qemu.exe -L 
"I:\debian4.0\QemuManager\qemu" -m 256 -hda 
"I:\debian4.0\debian4\debian4_0_qcow.dsk" -cdrom 
"I:\debian4.0\debian4\debian-testing-i386-DVD-1.iso" -kernel-kqemu -net 
nic,vlan=0 -net user,vlan=0 -std-vga -localtime

fsck on mounted filesystem: fsck -nv /dev/hda1 show no errors except # of free 
inodes
df 19% of system used (Total: 15409468 used: 2641020)
fill the rest of the disk: dd if=/dev/zero of=/tmp/bigfile bs=16M
dd stops with disk full, ok
now fsck -nv /dev/hda1 no errors
rm bigfile
shutdown system did work

image: debian4_0_qcow.dsk
file format: qcow
virtual size: 16G (16777216000 bytes)
disk size: 15G
cluster_size: 4096

Size of debian4_0_qcow.dsk: 15.919.493.120 Bytes

Start VM: all o.k.
-



___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/target-mips TODO

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 15:39:48

Modified files:
target-mips: TODO 

Log message:
Note FPU enable/disable issue.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/TODO?cvsroot=qemu&r1=1.5&r2=1.6


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/hw mips_r4k.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 15:21:30

Modified files:
hw : mips_r4k.c 

Log message:
Remove useless static specifier.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_r4k.c?cvsroot=qemu&r1=1.37&r2=1.38


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu exec.c vl.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 15:17:59

Modified files:
.  : exec.c vl.c 

Log message:
Better ioport debugging output.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.88&r2=1.89
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.264&r2=1.265


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] PXA-specific ARM hacks.

[Paul Brook]

On Friday 16 March 2007 22:06, andrzej zaborowski wrote:
> This patch contains some ugly but very useful chnages:
>  - in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other
> architectures.

This is ok. Though I'd prefer it to actually be common code (like 
CPU_INTERRUPT_DEBUG).

>  - wake the cpu up on CPU_INTERRUPT_EXITTB - this serves waking the
> CPU up without asserting IRQ or FIQ, which is possible on PXA. Would
> it be better to add a separate interrupt type instead?

I think this is probably ok. Could do with a comment somewhere saying so.

>  - in target-arm/translate.c, don't terminate the TB after a CP15
> write. The purpose of this is to imitate the real processor's
> instruction cache (to some degree). OSes should never need rely on the
> cache prefetch but unfortunately Linux for pxa does when it's waking
> up from sleep or deep idle, when enabling the MMU (simplifies things a
> lot for Linux).

This is not acceptable in its current form. IIRC on arm cores the effects take 
effect once all insn have worked through the pipeline (typically a few 
cycles), and I bet there's code that relies on this. ie:
mcr cp15, ...;nop;nop;nop;nop;@expect cp15 write to have taken effect by now

A more acceptable solution would be:
- Only extend the TB for the specific instruction that linux abuses
- Limit the number of instructions that can follow before the end of the TB.
- Add a comment saying what this hack is for.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu Makefile Makefile.target configure

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 15:00:38

Modified files:
.  : Makefile Makefile.target configure 

Log message:
Better way to select -lrt, by Andrzei Zaborowski.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.113&r2=1.114
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.147&r2=1.148
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.129&r2=1.130


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/hw ide.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 14:55:31

Modified files:
hw : ide.c 

Log message:
Don't fail for "revert to poweron defaults" IDE command, by Carlo
Marcelo Arenas Belon.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.55&r2=1.56


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/hw ide.c

[Thiemo Seufer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer  07/03/17 14:54:15

Modified files:
hw : ide.c 

Log message:
Allow disabling IDE block mode, by Carlo Marcelo Arenas Belon.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ide.c?cvsroot=qemu&r1=1.54&r2=1.55


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

RE: [Qemu-devel] qemu/target-ppc cpu.h exec.h helper.c op.c op_h...

[Wessel, Jason]

Hi Jocelyn,

Previously it was mentioned that there is a regression that was
introduced by your original merge on March 8, 2007.  I tested this
latest code and it is still there.  The nature of the problem is that
the networking does not work when booting QEMU and using the built in
slirp networking.  A dhcp packet will work but the udp and tcp packets
do not appear to send.

It appears that the packet check sum computed by the Linux network stack
is incorrect.  When the code in slirp/ip_input.c checks the checksum of
the udp or tcp packet it throws the packet away because the checksum was
invalid.  I took the code from March 7, 2007 in cvs for target-ppc/* and
used it with the latest of everything else and the packet checksums are
computed correct and the target boots with networking.  

This points to the problem being what ever instructions the kernel is
using to compute the checksum are not being translated correctly by your
latest changes.  The next step will be to take a closer look at which
instructions are used to compute the checksum.  I thought I might send
out some further analysis of the original stated problem in case you had
an idea of where to look to fix the problem off the top of your head.
If you have any ideas, please drop me some e-mail.

Also with regard to the 2.6.21 kernel and the ppc-prep machine, I
patched the kernel to make it send PCI interrupts the same way the prior
kernels did.  It seems there is a regression there inside the kernel in
the way that the IRQ acknowledgements are handled.  It could be that the
emulation is not right in QEMU, but I figure that mystery is one for
another day.  If you need a kernel that boots on the ppc-prep please let
me know.  I also patched the prep loader in the linux kernel so I could
boot an image that was larger than 4 megs.

Thanks,
Jason.

> -Original Message-
> From: 
> [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> rg] On Behalf Of Jocelyn Mayer
> Sent: Saturday, March 17, 2007 9:02 AM
> To: qemu-devel@nongnu.org
> Subject: [Qemu-devel] qemu/target-ppc cpu.h exec.h helper.c 
> op.c op_h...
> 
> CVSROOT:  /sources/qemu
> Module name:  qemu
> Changes by:   Jocelyn Mayer  07/03/17 14:02:15
> 
> Modified files:
>   target-ppc : cpu.h exec.h helper.c op.c op_helper.c 
>op_helper.h op_helper_mem.h op_mem.h 
>translate.c 
> 
> Log message:
>   Make it safe to use 64 bits GPR and/or 64 bits host registers.
>   For "symetry", add 64 bits versions of all modified functions.
>   As a side effect, add a lot of code provision for 
> PowerPC 64 support.
>   Move overflow and carry checks in common routines for 
> simple cases.
>   Add isel and popcntb instructions from PowerPC 2.03 
> specification.
>   Remove remaining micro-operations helpers prototypes from op.c.
>   Fix XER_BC field to be 7 bits long.
>   Add power management support for PowerPC 603 & 604.
>   Fix compilation warnings.
> 
> CVSWeb URLs:
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsr
> oot=qemu&r1=1.26&r2=1.27
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvs
> root=qemu&r1=1.15&r2=1.16
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?c
> vsroot=qemu&r1=1.32&r2=1.33
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsro
> ot=qemu&r1=1.23&r2=1.24
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.
> c?cvsroot=qemu&r1=1.18&r2=1.19
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.
> h?cvsroot=qemu&r1=1.1&r2=1.2
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper_
> mem.h?cvsroot=qemu&r1=1.7&r2=1.8
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?c
> vsroot=qemu&r1=1.8&r2=1.9
> http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.
> c?cvsroot=qemu&r1=1.44&r2=1.45
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] Add main PXA on-chip peripherals.

[andrzej zaborowski]

This adds the remaining on-chip peripherals of the PXA2xx:
- MMC/SD host.
- PCMCIA sockets.
- System timers.
- LCD controller. For the LCD I added the "-portrait" switch that
rotates the display 90 degrees left. This is for the Spitz machine
(clamshell based PDA) that can work in the two display modes. The
rotation can be changed in runtime when machine code decides so, for
example signaled by the OS through a GPIO. When the screen is being
rotated, the mouse clicks coordinates are also rotated so the guest OS
doesn't have to recalibrate input devices (i.e touchscreen).

[Apparently, this patch is too big for the list software, this time I
uploaded it at 
http://students.mimuw.edu.pl/~az258116/0007-Add-main-PXA-on-chip-peripherals.txt
instead of attaching. All 17 files I sent yesterday are in
http://students.mimuw.edu.pl/~az258116/qemu-pxa-patches.tar Sorry for
inconvenience]

Cheers,
Andrew


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] ARM XScale core features. PXA270 and PXA255 emulation.

[andrzej zaborowski]

Implements basic differences between XScale and plain ARM. The patch
also adds the main on-chip peripherals of PXA2xx: interrupt
controller, DMA, GPIO controller, SSP, I2C, I2S busses, UARTs, FIR
port, RTC, Clock/Power/Memory managers.

There's also an api to hook funcitons to coprocessor writes and reads
becaue PXA uses those in various on-chip peripherals (and they're
supposed to be faster than memory IO access to the same peripherals,
on the real hardware).

[Apparently, this patch is too big for the list software, this time I
uploaded it at 
http://students.mimuw.edu.pl/~az258116/0003-ARM-XScale-core-features.-PXA270-and-PXA255-emulation.txt
instead of attaching. All 17 files I sent yesterday are in
http://students.mimuw.edu.pl/~az258116/qemu-pxa-patches.tar ]

Cheers,
Andrew


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

[Thiemo Seufer]

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

> The current solution (1) is not good, because users get crashes
> and don't know the reason, and experienced users spend a lot of
> time with debugging (at least I did).
> 
> Solution (2) is needed to run existing binary code.
> 
> Solution (3) is the minimum I expect of an emulation like QEMU.
> 
> I prefer a mix of solutions (2) and (3): display a message and
> try to emulate the original behaviour.
> 
> Do you agree, and would you accept patches which implement this?

If the AR7 CPU spec defines the semantics of branch delay slots more
precisely than the architecture spec then I'll consider a patch.

If this isn't the case then I ask you to use a non-broken compiler/
assembly code.


Thiemo


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] [SPARC] SlavIO Counter-Timers fix

[Aurelien Jarno]

Hi all,

Currently, the time on the SPARC sun4m target running Linux goes about
30% too fast. 

This is due to a bug in the SlavIO Counter-Timers emulation. When in 
system mode the counter must be reset when a new limit is written, but 
*not* when the current limit is read (which also clears the interrupt).

The patch below fixes that.

Bye,
Aurelien

Index: hw/slavio_timer.c
===
RCS file: /sources/qemu/qemu/hw/slavio_timer.c,v
retrieving revision 1.4
diff -u -d -p -r1.4 slavio_timer.c
--- hw/slavio_timer.c   25 Jun 2006 18:15:31 -  1.4
+++ hw/slavio_timer.c   17 Mar 2007 14:07:31 -
@@ -131,7 +131,6 @@ static uint32_t slavio_timer_mem_readl(v
if (s->mode != 1) {
// clear irq
pic_set_irq_cpu(s->irq, 0, s->cpu);
-   s->count_load_time = qemu_get_clock(vm_clock);
s->reached = 0;
return s->limit;
}

-- 
  .''`.  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 configure

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/03/17 14:04:57

Modified files:
.  : configure 

Log message:
Add PowerPC 64 target for tests.
As no PowerPC 64 CPU is implemented, this target can just be used to 
check that
there is no difference between PowerPC 32 & PowerPC 64 used in 32 bits 
mode. 

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.128&r2=1.129


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/target-ppc cpu.h exec.h helper.c op.c op_h...

[Jocelyn Mayer]

CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/03/17 14:02:15

Modified files:
target-ppc : cpu.h exec.h helper.c op.c op_helper.c 
 op_helper.h op_helper_mem.h op_mem.h 
 translate.c 

Log message:
Make it safe to use 64 bits GPR and/or 64 bits host registers.
For "symetry", add 64 bits versions of all modified functions.
As a side effect, add a lot of code provision for PowerPC 64 support.
Move overflow and carry checks in common routines for simple cases.
Add isel and popcntb instructions from PowerPC 2.03 specification.
Remove remaining micro-operations helpers prototypes from op.c.
Fix XER_BC field to be 7 bits long.
Add power management support for PowerPC 603 & 604.
Fix compilation warnings.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.26&r2=1.27
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemu&r1=1.15&r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.32&r2=1.33
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.23&r2=1.24
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.18&r2=1.19
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper_mem.h?cvsroot=qemu&r1=1.7&r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_mem.h?cvsroot=qemu&r1=1.8&r2=1.9
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.44&r2=1.45


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

I'd like to add that with qemu 0.9.0 release it's the same problem,
that somehow seems to recurr from time to time (seen old similar
reports with older qemu release(s)) in helper.c.

We at SourceMage GNU/Linux got reports of failed builds with that error
that are apparently fixed by reducing -march cflag to pentium-mmx as
opposed to pentium2,3,4 or pentium-m as well as any athlon.
Any sse flags also seem to trigger this error.
qemu 0.8.6 built without probs with -march=pentium-m, for example (we
still use the same compiler gcc-3.4.6 for this).

There's a thread on the user forum, too:
http://qemu-forum.ipi.fi/viewtopic.php?p=10045#10045

Is there actually some policy on CFLAGS settings? I didn't find a FAQ
like "do not set any -march other than the most basic, qemu performance
is ruled by hand-crafted assembler anyway and -msse won't also not
help anything" .. should there be one?
I guess there is something hand-crafted fighting with gcc over
registers...


Thomas.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Bug] MIPS code fails at branch instruction

[Stefan Weil]

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.

The current solution (1) is not good, because users get crashes
and don't know the reason, and experienced users spend a lot of
time with debugging (at least I did).

Solution (2) is needed to run existing binary code.

Solution (3) is the minimum I expect of an emulation like QEMU.

I prefer a mix of solutions (2) and (3): display a message and
try to emulate the original behaviour.

Do you agree, and would you accept patches which implement this?

Stefan

PS. Emulation of undefined instructions / undefined behaviour has
a long tradition. In the old Z80 and 8086 days, it was
something like a game to analyse and use them :-)


Thiemo Seufer schrieb:
> Stefan Weil wrote:
>> QEMU MIPS emulation fails with code using "illegal" commands
>> in the delay slot of a branch.
>>
>> I had an endless loop with QEMU running the firmware of a
>> MIPS based router.
>>
>> MIPS says: branches, jumps, ... instructions should not be
>> placed in the delay slot of a branch or jump.
>>
>> Nevertheless, some routers use this kind of code.
>
> The architecture spec defines this as undefined behaviour. Other
> implementations of MIPS CPUs show funny effects which are hard
> to explain without detailed knowledge of the microarchitecture.
>
>> I wrote a test program to examine the difference between emulation
>> and a real MIPS CPU (see appendices).
>
> I wouldn't be surprised if it starts to fail for some other combinations
> like a mix of branch and branch likely instructions.
>
> (The semantics of a branch delay slot are: The instruction in the delay
> slot is executed, then the branch is executed. Now, when the instruction
> in the delay slot is itself a branch, what will happen to its delay slot?)
>
>
> Thiemo
>



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

[Axel Zeuner]

Hi,

On Saturday 17 March 2007 10:51, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 17 Mar 2007, axel wrote:
> > Why there exist two different blocks for COFF and ELF for x86/x86_64
> > hosts?
>
> Because COFF is used by Windows, and ELF by Linux, and they are
> substantially different?
>
Sorry, I did not want to criticise the code, I apologise for that.
But do these blocks different things? They should check for the last byte, 
strip off trailing padding bytes including the ret instruction and determine 
the size of the block of code to copy. Am I really wrong here?
>
> > @@ -1458,6 +1458,8 @@
> >  error("empty code for %s", name);
> >  if (p_end[-1] == 0xc3) {
> >  len--;
> > +   if ( len>0 && p_end[-2] == 0xf3 )
> > +   --len;
>
> This is wrong in several accounts:
>
> - style (space after opening parentheses and before closing parentheses,
>   no space before and after ">", "--" before instead of after "len", just
>   see the if clause above)
I agree, sorry for that, next time I will follow the coding rules. Most of my 
time I use C++ and there it makes sense to prefer prefix decrement and prefix 
increment operations for performance reasons.
> - if you want to access "p_end[-2]", you must check for "len > 1"
I do not agree, because len was decremented in the line above and len is a 
signed int and p_end was not changed. 
>
> - you most likely want to check "p_end[-1]" anyway
No, because p_end[-1] was already checked and is known to be 0xc3. I want to 
check the byte before p_end[-1], because repz; ret translates to 0xf3 0xc3
>
> - worst: there is no appropriate explanation why this patch is needed, and
The currently generated op_XXX functions are not affected by the stale repz 
prefixes at the end of the generated and copied blocks, but the following 
scenario is possible, at least in theory:
op_1:
movl $0,%%ecx
do_what_ever_but_do_not_change_ecx
repz; ret

op_2:
stosd
ret
Now the following op code sequence op_1, op_2 is generated. The resulting code 
in the code generation buffer will be
movl $0,%%ecx
do_what_ever_but_do_not_change_ecx
repz; # stale from op_1
stosd; # body of op_2
This is probably not what one wants to execute.
>   even more importantly, why it does not break existing code
I agree fully, as I mentioned, this is a HACK and WILL break existing code 
sooner or later. 

Kind regards
Axel

> Hth,
> Dscho
>
>
>
>
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] SecureDigital card emulation.

[andrzej zaborowski]

Hi,

On 17/03/07, Paul Brook <[EMAIL PROTECTED]> wrote:

On Friday 16 March 2007 20:59, andrzej zaborowski wrote:
> Emulates an SD card with the full command set (no SPI mode though).
> Should be more or less compliant with version 1.10 specification.

I suspect your code only works on x86. Specifically things like:

> +struct sd_response_r1_s {
> +uint8_t cmd;
> +uint32_t status;
> +uint8_t crc;
> +};

Will be a 12-byte struct on many hosts, and probably also breaks on big-endian
hosts. AFAICS there's no way for the caller of sd_write_cmdline to figure out
what type of response is returned (other than the length), so has to rely on
doing a bitwise copy.


The card is supposed to return the type of response matching the
command that was issued, so the the caller does know the type and
doesn't do bitwise copy. If the card is broken and returns a different
response then we get garbage, exactly like on the actual hardware.

Regards,
Andrew


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] SecureDigital card emulation.

[Paul Brook]

On Friday 16 March 2007 20:59, andrzej zaborowski wrote:
> Emulates an SD card with the full command set (no SPI mode though).
> Should be more or less compliant with version 1.10 specification.

I suspect your code only works on x86. Specifically things like:

> +struct sd_response_r1_s {
> +uint8_t cmd;
> +uint32_t status;
> +uint8_t crc;
> +};

Will be a 12-byte struct on many hosts, and probably also breaks on big-endian 
hosts. AFAICS there's no way for the caller of sd_write_cmdline to figure out 
what type of response is returned (other than the length), so has to rely on 
doing a bitwise copy.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Redundant repz prefixes in generated amd64 code

[Johannes Schindelin]

Hi,

On Sat, 17 Mar 2007, axel wrote:

> Why there exist two different blocks for COFF and ELF for x86/x86_64 
> hosts?

Because COFF is used by Windows, and ELF by Linux, and they are 
substantially different?

> @@ -1458,6 +1458,8 @@
>  error("empty code for %s", name);
>  if (p_end[-1] == 0xc3) {
>  len--;
> +   if ( len>0 && p_end[-2] == 0xf3 )
> +   --len;

This is wrong in several accounts:

- style (space after opening parentheses and before closing parentheses, 
  no space before and after ">", "--" before instead of after "len", just 
  see the if clause above)

- if you want to access "p_end[-2]", you must check for "len > 1"

- you most likely want to check "p_end[-1]" anyway

- worst: there is no appropriate explanation why this patch is needed, and 
  even more importantly, why it does not break existing code

Hth,
Dscho




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel