Re: [Qemu-devel] RFC: Code fetch optimisation

2007-10-14 Thread Paul Brook
On Sunday 14 October 2007, J. Mayer wrote:
> Here's an updated version of the code fetch optimisation patch against
> current CVS.
> As a remainder, this patch avoid use of softmmu helpers to fetch the
> code in most case. A new target define TARGET_HAS_VLE_INSNS has been
> added which is used to handle the case of an instruction that span 2
> pages, when the target CPU uses a variable-length instructions encoding.
> For pure RISC, the code fetch is done using raw access routines.

> +unsigned long phys_pc;
> +unsigned long phys_pc_start;

These are ram offsets, not physical addresses. I recommend naming them as such 
to avoid confusion.

> +opc = glue(glue(lds,SUFFIX),MEMSUFFIX)(virt_pc);
> +/* Avoid softmmu access on next load */
> +/* XXX: dont: phys PC is not correct anymore
> + *  We could call get_phys_addr_code(env, pc); and remove the else
> + *  condition, here. 
> + */
> +//*start_pc = phys_pc;

The commented out code is completely bogus, please remove it. The comment is 
also somewhat misleading/incorrect. The else would still be required for 
accesses that span a page boundary.

The code itself looks ok, though I'd be surprised if it made a significant 
difference. We're always going to hit the fast-path TLB lookup case anyway.

Paul




[Qemu-devel] [PATCH] Arm MMU Fixes

2007-10-14 Thread Matthew Warton

Hi,

I recently tracked down a problem in the simulation of our software  
on Qemu to two small problems in the ARM MMU code.


The first is that Qemu would not enable changing of the pid register  
on processors with an MMU.  This is a legal operation, and one that  
several parts of our kernel rely on.  See (for example) the ARM920t  
technical reference manual to verify that this register is available  
on ARM processors with an MMU.


The second fix is more subtle.  The Qemu TLB is architecture  
independent, and therefore does not track Domains with TLB entries.   
Thus when the domain register is changed the TLB needs to be flushed  
so that all of the memory accesses are again checked with the new  
permissions.  The lack of this flush was causing a protection fault  
to not be delivered in certain circumstances, leading to incorrect  
software execution.


I would appreciate it if you could incorporate this patch into future  
releases of Qemu.


Thankyou,
Matthew Warton

Open Kernel Labs
www.ok-labs.com



arm.diff
Description: Binary data


Re: [Qemu-devel] QEMU/MIPS & dyntick kernel

2007-10-14 Thread Paul Brook
> There seem to have specific problems when using dynticks in Qemu. What I
> can see is that it makes the PowerPC emulation quite unusable, at least
> on my PC, which is an amd64 (with a fix CPU frequency), no matter if I
> run 32 or 64 bits mode.

I'd expect to see the same problems running a non-dynticks qemu on a heavily 
loaded host, or a host that did not have /dev/rtc available.

IIRC vanilla amd64-linux does not yet use the new kernel high resolution timer 
infrastructure, so posix timers (as used by dynticks) have a fairly high 
jitter+latency compared to /dev/rtc.

The tradeoff is that on hosts that do implement high resolution timers (e.g. 
i386) you get lower overhead and/or more accurate emulation. I don't think 
there's any deterministic way of figuring out which is best. It may be 
feasible to switch mechanisms dynamically if it's obvious one is sucking, but 
I'm not sure how well that would work in practice.

The only reliable solution is to isolate qemu from the host realtime 
characteristics, though that has its own set of issues. I hope to have this 
implemented fairly soon.

Paul




Re: [Qemu-devel] What happened with NPTL/TLS support?

2007-10-14 Thread Paul Brook
On Friday 12 October 2007, Felipe Contreras wrote:
> Hi,
>
> When I try to use codesourcery's toolchain arm-2006q3-27 in my Fedora
> 7 box I always have the following issue:
>
> qemu: Unsupported syscall: 983045
>
> I guess it's a problem of NPTL incompatibility. Anyway, the patch that
> Paul Brook sent a while ago solves it [1].
>
> I wonder if it can be integrated or what would be the right way to
> solve this issue. Am I the only one having it?

It needs someone to care enough to make the implementation not suck.

Paul




[Qemu-devel] qemu/target-sparc op_helper.c

2007-10-14 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/14 20:27:01

Modified files:
target-sparc   : op_helper.c 

Log message:
 Fix bug in Sparc32 sta op (Robert Reif)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.44&r2=1.45




Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores

2007-10-14 Thread Blue Swirl
On 10/14/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> Use stq_* for 64 bit stores.

I changed also uses of 64 bit loads to ldq. But it looks like this
makes OpenBIOS trigger alignment traps, this is the same reason why
the alignment checks aren't fully enabled. So I can't commit this yet
except for the buggy store fix.
Index: target-sparc/op_helper.c
===
--- target-sparc/op_helper.c.orig	2007-10-14 17:01:52.0 +
+++ target-sparc/op_helper.c	2007-10-14 19:48:20.0 +
@@ -170,6 +170,7 @@
 void helper_ld_asi(int asi, int size, int sign)
 {
 uint32_t ret = 0;
+uint64_t tmp;
 #ifdef DEBUG_MXCC
 uint32_t last_T0 = T0;
 #endif
@@ -244,8 +245,9 @@
 ret = ldl_code(T0 & ~3);
 break;
 case 8:
-ret = ldl_code(T0 & ~3);
-T0 = ldl_code((T0 + 4) & ~3);
+tmp = ldq_code(T0 & ~7);
+ret = tmp >> 32;
+T0 = tmp & 0x;
 break;
 }
 break;
@@ -262,8 +264,9 @@
 ret = ldl_user(T0 & ~3);
 break;
 case 8:
-ret = ldl_user(T0 & ~3);
-T0 = ldl_user((T0 + 4) & ~3);
+tmp = ldq_user(T0 & ~7);
+ret = tmp >> 32;
+T0 = tmp & 0x;
 break;
 }
 break;
@@ -280,8 +283,9 @@
 ret = ldl_kernel(T0 & ~3);
 break;
 case 8:
-ret = ldl_kernel(T0 & ~3);
-T0 = ldl_kernel((T0 + 4) & ~3);
+tmp = ldq_kernel(T0 & ~7);
+ret = tmp >> 32;
+T0 = tmp & 0x;
 break;
 }
 break;
@@ -303,8 +307,9 @@
 ret = ldl_phys(T0 & ~3);
 break;
 case 8:
-ret = ldl_phys(T0 & ~3);
-T0 = ldl_phys((T0 + 4) & ~3);
+tmp = ldq_phys(T0 & ~7);
+ret = tmp >> 32;
+T0 = tmp & 0x;
 break;
 }
 break;
@@ -325,10 +330,10 @@
| ((target_phys_addr_t)(asi & 0xf) << 32));
 break;
 case 8:
-ret = ldl_phys((target_phys_addr_t)(T0 & ~3)
-   | ((target_phys_addr_t)(asi & 0xf) << 32));
-T0 = ldl_phys((target_phys_addr_t)((T0 + 4) & ~3)
+tmp = ldq_phys((target_phys_addr_t)(T0 & ~7)
| ((target_phys_addr_t)(asi & 0xf) << 32));
+ret = tmp >> 32;
+T0 = tmp & 0x;
 break;
 }
 break;
@@ -515,8 +520,7 @@
 stl_user(T0 & ~3, T1);
 break;
 case 8:
-stl_user(T0 & ~3, T1);
-stl_user((T0 + 4) & ~3, T2);
+stq_user(T0 & ~7, ((uint64_t)T1 << 32) | T2);
 break;
 }
 break;
@@ -533,8 +537,7 @@
 stl_kernel(T0 & ~3, T1);
 break;
 case 8:
-stl_kernel(T0 & ~3, T1);
-stl_kernel((T0 + 4) & ~3, T2);
+stq_kernel(T0 & ~7, ((uint64_t)T1 << 32) | T2);
 break;
 }
 break;
@@ -591,8 +594,7 @@
 stl_phys(T0 & ~3, T1);
 break;
 case 8:
-stl_phys(T0 & ~3, T1);
-stl_phys((T0 + 4) & ~3, T2);
+stq_phys(T0 & ~7, ((uint64_t)T1 << 32) | T2);
 break;
 }
 }
@@ -615,10 +617,8 @@
| ((target_phys_addr_t)(asi & 0xf) << 32), T1);
 break;
 case 8:
-stl_phys((target_phys_addr_t)(T0 & ~3)
-   | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
-stl_phys((target_phys_addr_t)((T0 + 4) & ~3)
-   | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
+stq_phys((target_phys_addr_t)(T0 & ~7)
+   | ((target_phys_addr_t)(asi & 0xf) << 32), ((uint64_t)T1 << 32) | T2);
 break;
 }
 }
Index: target-sparc/op_mem.h
===
--- target-sparc/op_mem.h.orig	2007-10-14 19:41:01.0 +
+++ target-sparc/op_mem.h	2007-10-14 19:55:02.0 +
@@ -36,8 +36,7 @@
 
 void OPPROTO glue(op_std, MEMSUFFIX)(void)
 {
-glue(stl, MEMSUFFIX)(ADDR(T0), T1);
-glue(stl, MEMSUFFIX)((ADDR(T0 + 4)), T2);
+glue(stq, MEMSUFFIX)(ADDR(T0), (T1 << 32) | (T2 & 0x));
 }
 
 void OPPROTO glue(op_ldstub, MEMSUFFIX)(void)
@@ -55,8 +54,11 @@
 
 void OPPROTO glue(op_ldd, MEMSUFFIX)(void)
 {
-T1 = glue(ldl, MEMSUFFIX)(ADDR(T0));
-T0 = glue(ldl, MEMSUFFIX)((ADDR(T0 + 4)));
+target_ulong tmp;
+
+tmp = glue(ldq, MEMSUFFIX)(ADDR(T0));
+T1 = tmp >> 32;
+T0 = tmp & 0x;
 }
 
 /*** Floating-point store  ***/


Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores

2007-10-14 Thread Blue Swirl
On 10/14/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> Blue Swirl wrote:
>
> >On 10/14/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Should the address be 64 bit alligned?  i.e. T0 & ~7 rather than T0 & ~3?
> >>
> >>Should these unaligned address cause traps?
> >>
> >>
> >
> >Yes, but the checks are already generated from translate.c
> >(gen_op_check_align_T0_7).
> >
> >
> De we to align then again?

The checks aren't fully enabled yet.




Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores

2007-10-14 Thread Robert Reif

Blue Swirl wrote:


On 10/14/07, Robert Reif <[EMAIL PROTECTED]> wrote:
 


Should the address be 64 bit alligned?  i.e. T0 & ~7 rather than T0 & ~3?

Should these unaligned address cause traps?
   



Yes, but the checks are already generated from translate.c
(gen_op_check_align_T0_7).
 


De we to align then again?





Re: [Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores

2007-10-14 Thread Blue Swirl
On 10/14/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> Use stq_* for 64 bit stores.

This could be less optimal for 32 bit hosts, but hopefully the
compiler knows its business.

> This fixes one bug where T1 was used twice rather than T1 and T2.

Great!

> Should the address be 64 bit alligned?  i.e. T0 & ~7 rather than T0 & ~3?
>
> Should these unaligned address cause traps?

Yes, but the checks are already generated from translate.c
(gen_op_check_align_T0_7).




[Qemu-devel] [PATCH] sparc32 use stq_* for 64bit stores

2007-10-14 Thread Robert Reif

Use stq_* for 64 bit stores.

This fixes one bug where T1 was used twice rather than T1 and T2.

Should the address be 64 bit alligned?  i.e. T0 & ~7 rather than T0 & ~3?

Should these unaligned address cause traps?

Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.44
diff -p -u -r1.44 op_helper.c
--- target-sparc/op_helper.c14 Oct 2007 17:07:21 -  1.44
+++ target-sparc/op_helper.c14 Oct 2007 18:28:37 -
@@ -515,8 +515,7 @@ void helper_st_asi(int asi, int size)
 stl_user(T0 & ~3, T1);
 break;
 case 8:
-stl_user(T0 & ~3, T1);
-stl_user((T0 + 4) & ~3, T2);
+stq_user(T0 & ~3, ((uint64_t)T1 << 32) | T2);
 break;
 }
 break;
@@ -533,8 +532,7 @@ void helper_st_asi(int asi, int size)
 stl_kernel(T0 & ~3, T1);
 break;
 case 8:
-stl_kernel(T0 & ~3, T1);
-stl_kernel((T0 + 4) & ~3, T2);
+stq_kernel(T0 & ~3, ((uint64_t)T1 << 32) | T2);
 break;
 }
 break;
@@ -591,8 +589,7 @@ void helper_st_asi(int asi, int size)
 stl_phys(T0 & ~3, T1);
 break;
 case 8:
-stl_phys(T0 & ~3, T1);
-stl_phys((T0 + 4) & ~3, T2);
+stq_phys(T0 & ~3, ((uint64_t)T1 << 32) | T2);
 break;
 }
 }
@@ -615,10 +612,8 @@ void helper_st_asi(int asi, int size)
| ((target_phys_addr_t)(asi & 0xf) << 32), T1);
 break;
 case 8:
-stl_phys((target_phys_addr_t)(T0 & ~3)
-   | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
-stl_phys((target_phys_addr_t)((T0 + 4) & ~3)
-   | ((target_phys_addr_t)(asi & 0xf) << 32), T1);
+stq_phys((target_phys_addr_t)(T0 & ~3)
+   | ((target_phys_addr_t)(asi & 0xf) << 32), 
((uint64_t)T1 << 32) | T2);
 break;
 }
 }


[Qemu-devel] qemu/target-sparc cpu.h op.c op_helper.c transl...

2007-10-14 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/14 17:07:21

Modified files:
target-sparc   : cpu.h op.c op_helper.c translate.c 

Log message:
 Sparc64 hypervisor mode

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemu&r1=1.55&r2=1.56
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemu&r1=1.42&r2=1.43
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.43&r2=1.44
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.76&r2=1.77




[Qemu-devel] qemu hw/sun4m.c hw/sun4u.c linux-user/main.c ta...

2007-10-14 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/14 16:29:21

Modified files:
hw : sun4m.c sun4u.c 
linux-user : main.c 
target-sparc   : cpu.h op_helper.c translate.c 

Log message:
 SuperSparc MXCC support (Robert Reif)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.55&r2=1.56
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4u.c?cvsroot=qemu&r1=1.22&r2=1.23
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.133&r2=1.134
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/cpu.h?cvsroot=qemu&r1=1.54&r2=1.55
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemu&r1=1.42&r2=1.43
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.75&r2=1.76




[Qemu-devel] qemu Makefile.target configure thunk.c thunk.h ...

2007-10-14 Thread Blue Swirl
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl   07/10/14 16:27:31

Modified files:
.  : Makefile.target configure thunk.c thunk.h 
linux-user : elfload.c elfload32.c flat.h flatload.c 
 linuxload.c main.c mmap.c qemu.h signal.c 
 syscall.c syscall_defs.h vm86.c 
linux-user/alpha: syscall.h target_signal.h 
linux-user/arm : syscall.h target_signal.h 
linux-user/cris: target_signal.h 
linux-user/i386: syscall.h target_signal.h 
linux-user/m68k: syscall.h target_signal.h 
linux-user/mips: syscall.h target_signal.h 
linux-user/mips64: syscall.h target_signal.h 
linux-user/ppc : syscall.h target_signal.h 
linux-user/ppc64: syscall.h target_signal.h 
linux-user/sh4 : target_signal.h 
linux-user/sparc: syscall.h target_signal.h 
linux-user/sparc64: syscall.h target_signal.h 
linux-user/x86_64: syscall.h target_signal.h 
target-sparc   : op_mem.h 

Log message:
 Support for 32 bit ABI on 64 bit targets (only enabled Sparc64)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.209&r2=1.210
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.162&r2=1.163
http://cvs.savannah.gnu.org/viewcvs/qemu/thunk.c?cvsroot=qemu&r1=1.8&r2=1.9
http://cvs.savannah.gnu.org/viewcvs/qemu/thunk.h?cvsroot=qemu&r1=1.14&r2=1.15
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemu&r1=1.51&r2=1.52
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload32.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flat.h?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemu&r1=1.7&r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/linuxload.c?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemu&r1=1.132&r2=1.133
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mmap.c?cvsroot=qemu&r1=1.16&r2=1.17
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemu&r1=1.40&r2=1.41
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemu&r1=1.45&r2=1.46
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemu&r1=1.139&r2=1.140
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemu&r1=1.42&r2=1.43
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/vm86.c?cvsroot=qemu&r1=1.11&r2=1.12
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/alpha/syscall.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/alpha/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/arm/syscall.h?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/arm/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/cris/target_signal.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/i386/syscall.h?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/i386/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/m68k/syscall.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/m68k/target_signal.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips/syscall.h?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips/target_signal.h?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips64/syscall.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips64/target_signal.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/syscall.h?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/syscall.h?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/ppc64/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/sh4/target_signal.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/sparc/syscall.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/sparc/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/sparc64/syscall.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/sparc64/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/x86_64/syscall.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/x86_64/target_signal.h?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_mem.h?cvsr

[Qemu-devel] [PATCH] sparc32: add MXCC support

2007-10-14 Thread Robert Reif

Updated patch base of feedback.

This patch adds SuperSparc MXCC support.
DPRINTF_MMU and DPRINTF_MXCC added.

I decided not to use do_unassigned_access() at this time because I don't 
know what real hardware does.
Index: hw/sun4m.c
===
RCS file: /sources/qemu/qemu/hw/sun4m.c,v
retrieving revision 1.55
diff -p -u -r1.55 sun4m.c
--- hw/sun4m.c  6 Oct 2007 11:28:21 -   1.55
+++ hw/sun4m.c  14 Oct 2007 15:07:52 -
@@ -327,7 +327,7 @@ static void *sun4m_hw_init(const struct 
 
 for(i = 0; i < smp_cpus; i++) {
 env = cpu_init();
-cpu_sparc_register(env, def);
+cpu_sparc_register(env, def, i);
 envs[i] = env;
 if (i == 0) {
 qemu_register_reset(main_cpu_reset, env);
Index: linux-user/main.c
===
RCS file: /sources/qemu/qemu/linux-user/main.c,v
retrieving revision 1.132
diff -p -u -r1.132 main.c
--- linux-user/main.c   12 Oct 2007 06:47:46 -  1.132
+++ linux-user/main.c   14 Oct 2007 15:07:53 -
@@ -2139,7 +2139,7 @@ int main(int argc, char **argv)
 fprintf(stderr, "Unable to find Sparc CPU definition\n");
 exit(1);
 }
-cpu_sparc_register(env, def);
+cpu_sparc_register(env, def, 0);
env->pc = regs->pc;
env->npc = regs->npc;
 env->y = regs->y;
Index: target-sparc/cpu.h
===
RCS file: /sources/qemu/qemu/target-sparc/cpu.h,v
retrieving revision 1.53
diff -p -u -r1.53 cpu.h
--- target-sparc/cpu.h  12 Oct 2007 06:47:46 -  1.53
+++ target-sparc/cpu.h  14 Oct 2007 15:07:53 -
@@ -210,6 +210,8 @@ typedef struct CPUSPARCState {
 uint64_t dtlb_tte[64];
 #else
 uint32_t mmuregs[16];
+uint64_t mxccdata[4];
+uint64_t mxccregs[8];
 #endif
 /* temporary float registers */
 float32 ft0, ft1;
@@ -266,7 +268,7 @@ int cpu_sparc_close(CPUSPARCState *s);
 int sparc_find_by_name (const unsigned char *name, const sparc_def_t **def);
 void sparc_cpu_list (FILE *f, int (*cpu_fprintf)(FILE *f, const char *fmt,
  ...));
-int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def);
+int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def, unsigned 
int cpu);
 
 #define GET_PSR(env) (env->version | (env->psr & PSR_ICC) | \
   (env->psref? PSR_EF : 0) |\
Index: target-sparc/op_helper.c
===
RCS file: /sources/qemu/qemu/target-sparc/op_helper.c,v
retrieving revision 1.41
diff -p -u -r1.41 op_helper.c
--- target-sparc/op_helper.c1 Oct 2007 17:07:58 -   1.41
+++ target-sparc/op_helper.c14 Oct 2007 15:07:54 -
@@ -2,9 +2,24 @@
 
 //#define DEBUG_PCALL
 //#define DEBUG_MMU
+//#define DEBUG_MXCC
 //#define DEBUG_UNALIGNED
 //#define DEBUG_UNASSIGNED
 
+#ifdef DEBUG_MMU
+#define DPRINTF_MMU(fmt, args...) \
+do { printf("MMU: " fmt , ##args); } while (0)
+#else
+#define DPRINTF_MMU(fmt, args...)
+#endif
+
+#ifdef DEBUG_MXCC
+#define DPRINTF_MXCC(fmt, args...) \
+do { printf("MXCC: " fmt , ##args); } while (0)
+#else
+#define DPRINTF_MXCC(fmt, args...)
+#endif
+
 void raise_exception(int tt)
 {
 env->exception_index = tt;
@@ -139,12 +154,57 @@ GEN_FCMP(fcmped_fcc3, float64, DT0, DT1,
 
 #ifndef TARGET_SPARC64
 #ifndef CONFIG_USER_ONLY
+
+#ifdef DEBUG_MXCC
+void dump_mxcc(CPUState *env)
+{
+printf("mxccdata: %016llx %016llx %016llx %016llx\n",
+env->mxccdata[0], env->mxccdata[1], env->mxccdata[2], 
env->mxccdata[3]);
+printf("mxccregs: %016llx %016llx %016llx %016llx\n"
+   "  %016llx %016llx %016llx %016llx\n",
+env->mxccregs[0], env->mxccregs[1], env->mxccregs[2], env->mxccregs[3],
+env->mxccregs[4], env->mxccregs[5], env->mxccregs[6], 
env->mxccregs[7]);
+}
+#endif
+
 void helper_ld_asi(int asi, int size, int sign)
 {
 uint32_t ret = 0;
+#ifdef DEBUG_MXCC
+uint32_t last_T0 = T0;
+#endif
 
 switch (asi) {
 case 2: /* SuperSparc MXCC registers */
+switch (T0) {
+case 0x01c00a00: /* MXCC control register */
+if (size == 8) {
+ret = env->mxccregs[3];
+T0 = env->mxccregs[3] >> 32;
+} else
+DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0, 
size);
+break;
+case 0x01c00a04: /* MXCC control register */
+if (size == 4)
+ret = env->mxccregs[3];
+else
+DPRINTF_MXCC("%08x: unimplemented access size: %d\n", T0, 
size);
+break;
+case 0x01c00f00: /* MBus port address register */
+if (size == 8) {
+ret = env->mxccregs[7];
+T0 = env->mxccregs[7] >> 32;
+} else
+DPRINTF_M

Re: [kvm-devel] [Qemu-devel] [PATCH] Fix color problems with sdl on bgr displays

2007-10-14 Thread Avi Kivity

Blue Swirl wrote:

On 10/14/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
  

Some kvm users complained that the blue and red channels are flipped on
their displays.  Reverting sdl.c rev 1.40 fixed that problem, so
apparently that commit made the problem larger than it was previously.

Attached a patch the removes the commit and fixes the problem.  Please
apply.



But this commit was previously reported as the best solution for OSX
(Intel, PPC) and Linux/PPC:
http://article.gmane.org/gmane.comp.emulators.qemu/18071

What kind of machines are the users using?
  


No idea, but I got two xdpyinfo logs and both indicated a bgr display.

Perhaps we see here a difference between how SDL behaves on different 
platforms.  Or maybe the test needs to be more subtle.


I haven't had any reports of wrong colors before; of course kvm users 
don't run Linux/PPC os OSX/anything.


--
error compiling committee.c: too many arguments to function





Re: [Qemu-devel] [PATCH] Fix color problems with sdl on bgr displays

2007-10-14 Thread Blue Swirl
On 10/14/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Some kvm users complained that the blue and red channels are flipped on
> their displays.  Reverting sdl.c rev 1.40 fixed that problem, so
> apparently that commit made the problem larger than it was previously.
>
> Attached a patch the removes the commit and fixes the problem.  Please
> apply.

But this commit was previously reported as the best solution for OSX
(Intel, PPC) and Linux/PPC:
http://article.gmane.org/gmane.comp.emulators.qemu/18071

What kind of machines are the users using?




[Qemu-devel] [PATCH] Fix color problems with sdl on bgr displays

2007-10-14 Thread Avi Kivity
Some kvm users complained that the blue and red channels are flipped on 
their displays.  Reverting sdl.c rev 1.40 fixed that problem, so 
apparently that commit made the problem larger than it was previously.


Attached a patch the removes the commit and fixes the problem.  Please 
apply.


--
error compiling committee.c: too many arguments to function

Index: sdl.c
===
RCS file: /sources/qemu/qemu/sdl.c,v
retrieving revision 1.44
diff -u -r1.44 sdl.c
--- sdl.c	17 Sep 2007 08:09:45 -	1.44
+++ sdl.c	14 Oct 2007 13:49:37 -
@@ -87,7 +87,7 @@
 ds->data = screen->pixels;
 ds->linesize = screen->pitch;
 ds->depth = screen->format->BitsPerPixel;
-if (screen->format->Bshift > screen->format->Rshift) {
+if (ds->depth == 32 && screen->format->Rshift == 0) {
 ds->bgr = 1;
 } else {
 ds->bgr = 0;


Re: [Qemu-devel] [RFC] sparc32 MXCC support

2007-10-14 Thread Robert Reif

Blue Swirl wrote:


On 10/13/07, Robert Reif <[EMAIL PROTECTED]> wrote:
 


I'm trying to add SuperSparc II MXCC support and need some feedback.

Is there a better way to read and write physical memory in 64bit chunks?
I'm not sure what I'm doing is portable between 32/64 and big/little endian.
   



Thank you for your effort. Applying the patch allows NetBSD on SS-10
to boot as far as on SS-5, previously it crashed.

I think the code is portable, but I think changing the register type
to uint32_t and using a DPRINTF system like used in for example
hw/iommu.c should make the code slightly clearer.


I don't have access to chip specs but from reading linux and *bsd code it
appears that the registers are 64 bits wide but sometimes accessed as 32 
bits to get

only the bottom 32 bits.  Do you mean using two uint32_t for a 64 bit
register?  How about a union of 2 uint32_t and a uint64_t.  Is that 
portable?
Never mind.  I just found out there is an ldq_phys and stq_phys.  I'll 
use those.


I looked at DPRINTF but would need a DPRINTF_MMU and DPRINTF_MXCC ...
Would that be acceptable?



For the memory access, ldl/q_phys/stl/q_phys is used in other block
copy routines. For longer blocks or if the address can be unaligned,
cpu_physical_memory_read() could be a better choice.
 

 


+int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def, int cpu);
   



unsigned int cpu?
 


OK


+printf("ERROR: helper_ld_asi(asi = %d, size = %d, sign = %d) T0 = 
%08x: unsupported size\n", asi, size, sign, T0);
   



If it's an error to access the registers with different size, you
should use do_unassigned_access() to report this.

 

These are more for me to make sure I catch all the necessary accesses 
without adding unnecessary code.
linux 2.4 and netbsd only use the ones I have implemented.  openboot 
uses more and
also some undocumented ones which are caught by this but I don't know 
how to handle

them yet.  I will use do_unassigned_access where necessary now.

Thanks for the review.





Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

2007-10-14 Thread Thiemo Seufer
J. Mayer wrote:
[snip]
> > > Here's a new version. The only change is that, for consistency, I did
> > > add the big-endian and little-endian accessors that were documented in
> > > cpu-all.h as unimplemented. The implementation is quite trivial, having
> > > native and reverse-endian accessors available, and changes functionnally
> > > nothing to the previous version.
> > 
> > The patch does not apply anymore. The Sparc part looks OK.
> > 
> > The benefits from the patch can be gained by mapping Sparc64 lduw and
> > ldsw in op_mem.h  directly to ldul and ldsl using SPARC_LD_OP and
> > replacing the ldl+bswap etc. for the LE cases with ldlr in
> > op_helper.c. If you prefer, I can do this after you have applied the
> > patch.
> 
> Yes, there are conflicts between this patch and the mmu_idx one I just
> commited. I will regenerate an updated diff in the hours to come, after
> I finished commiting the PowerPC fixes and improvments I got waiting in
> stock.
> For the Sparc improvments, as I merged the PowerPC improvments in the
> patch, I think it can be a good idea to include it directly in the
> patch.
> I'm also wondering if it would not be a good idea to define lduq/ldsq
> even if they in fact do exactly what ldq does now, just to have a fully
> consistent API.

Some architecture specs mention the possibility of 128 bit integers, so
this sounds like a good idea.


Thiemo




Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

2007-10-14 Thread Blue Swirl
On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> Here's an updated version of the patch against current CVS.
> This patches provides reverse-endian, little-endian and big-endian
> memory accessors, available with and without softmmu. It also provides
> an IO_MEM_REVERSE TLB flag to allow future support of per-page
> endianness control, which is required by some targets CPU emulations.
> Having reverse-endian memory accessors also make it possible to optimise
> reverse-endian memory access when the target CPU has dedicated
> instructions. For now, it includes optimisations for the PowerPC target.

This breaks Sparc32 softmmu, I get a black screen. Your changes to
target-sparc and hw/sun4m.c look fine, so the problem could be in IO?




[Qemu-devel] Qemu build dependencies

2007-10-14 Thread J. Mayer
Following the discussion initiated last week about Qemu build
dependencies, I do propose to include the included patch (or the one
that was previously proposed that was very close to this one).
Please tell about any objection or improvments suggestions.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: Makefile.target
===
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.209
diff -u -d -d -p -r1.209 Makefile.target
--- Makefile.target	14 Oct 2007 08:38:29 -	1.209
+++ Makefile.target	14 Oct 2007 10:25:11 -
@@ -24,7 +24,7 @@ TARGET_BASE_ARCH:=sparc
 endif
 TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
 VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio
-CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH)
+CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH) -MMD -MP
 ifdef CONFIG_DARWIN_USER
 VPATH+=:$(SRC_PATH)/darwin-user
 CPPFLAGS+=-I$(SRC_PATH)/darwin-user -I$(SRC_PATH)/darwin-user/$(TARGET_ARCH)
@@ -636,58 +642,6 @@ cpu-exec.o: cpu-exec.c
 signal.o: signal.c
 	$(CC) $(HELPER_CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $<
 
-vga.o: pixel_ops.h
-
-tcx.o: pixel_ops.h
-
-ifeq ($(TARGET_BASE_ARCH), i386)
-op.o: op.c opreg_template.h ops_template.h ops_template_mem.h ops_mem.h ops_sse.h
-endif
-
-ifeq ($(TARGET_ARCH), arm)
-op.o: op.c op_template.h
-pl110.o: pl110_template.h
-endif
-
-ifeq ($(TARGET_BASE_ARCH), sparc)
-helper.o: cpu.h exec-all.h
-op.o: op.c op_template.h op_mem.h fop_template.h fbranch_template.h exec.h cpu.h
-op_helper.o: exec.h softmmu_template.h cpu.h
-translate.o: cpu.h exec-all.h disas.h
-endif
-
-ifeq ($(TARGET_BASE_ARCH), ppc)
-op.o: op.c op_template.h op_mem.h op_helper.h
-op_helper.o: op_helper.c mfrom_table.c op_helper_mem.h op_helper.h
-translate.o: translate.c translate_init.c
-endif
-
-ifeq ($(TARGET_BASE_ARCH), mips)
-helper.o: cpu.h exec-all.h
-op.o: op_template.c fop_template.c op_mem.c exec.h cpu.h
-op_helper.o: exec.h softmmu_template.h cpu.h
-translate.o: translate_init.c exec-all.h disas.h
-endif
-
-loader.o: loader.c elf_ops.h
-
-ifeq ($(TARGET_ARCH), sh4)
-op.o: op.c op_mem.c cpu.h
-op_helper.o: op_helper.c exec.h cpu.h
-helper.o: helper.c exec.h cpu.h
-sh7750.o: sh7750.c sh7750_regs.h sh7750_regnames.h cpu.h
-shix.o: shix.c sh7750_regs.h sh7750_regnames.h
-sh7750_regnames.o: sh7750_regnames.c sh7750_regnames.h sh7750_regs.h
-tc58128.o: tc58128.c
-endif
-
-ifeq ($(TARGET_BASE_ARCH), alpha)
-op.o: op.c op_template.h op_mem.h
-op_helper.o: op_helper_mem.h
-endif
-
-$(OBJS) $(LIBOBJS) $(VL_OBJS): config.h ../config-host.h
-
 %.o: %.c
 	$(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $<
 
@@ -695,7 +649,8 @@ $(OBJS) $(LIBOBJS) $(VL_OBJS): config.h 
 	$(CC) $(CPPFLAGS) -c -o $@ $<
 
 clean:
-	rm -f *.o  *.a *~ $(PROGS) gen-op.h opc.h op.h nwfpe/*.o slirp/*.o fpu/*.o
+	rm -f *.o *.a *~ $(PROGS) gen-op.h opc.h op.h nwfpe/*.o slirp/*.o fpu/*.o
+	rm -f *.d */*.d
 
 install: all
 ifneq ($(PROGS),)
@@ -711,3 +666,6 @@ audio.o sdlaudio.o dsoundaudio.o ossaudi
 fmodaudio.o alsaaudio.o mixeng.o sb16.o es1370.o gus.o adlib.o: \
 CFLAGS := $(CFLAGS) -Wall -Werror -W -Wsign-compare
 endif
+
+# Include automatically generated dependency files
+-include $(wildcard *.d */*.d)


[Qemu-devel] RFC: Code fetch optimisation

2007-10-14 Thread J. Mayer
Here's an updated version of the code fetch optimisation patch against
current CVS.
As a remainder, this patch avoid use of softmmu helpers to fetch the
code in most case. A new target define TARGET_HAS_VLE_INSNS has been
added which is used to handle the case of an instruction that span 2
pages, when the target CPU uses a variable-length instructions encoding.
For pure RISC, the code fetch is done using raw access routines.


-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized
Index: cpu-all.h
===
RCS file: /sources/qemu/qemu/cpu-all.h,v
retrieving revision 1.76
diff -u -d -d -p -r1.76 cpu-all.h
--- cpu-all.h	23 Sep 2007 15:28:03 -	1.76
+++ cpu-all.h	14 Oct 2007 11:35:53 -
@@ -646,6 +646,13 @@ static inline void stfq_be_p(void *ptr, 
 #define ldl_code(p) ldl_raw(p)
 #define ldq_code(p) ldq_raw(p)
 
+#define ldub_code_p(sp, pp, p) ldub_raw(p)
+#define ldsb_code_p(sp, pp, p) ldsb_raw(p)
+#define lduw_code_p(sp, pp, p) lduw_raw(p)
+#define ldsw_code_p(sp, pp, p) ldsw_raw(p)
+#define ldl_code_p(sp, pp, p) ldl_raw(p)
+#define ldq_code_p(sp, pp, p) ldq_raw(p)
+
 #define ldub_kernel(p) ldub_raw(p)
 #define ldsb_kernel(p) ldsb_raw(p)
 #define lduw_kernel(p) lduw_raw(p)
Index: cpu-exec.c
===
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.120
diff -u -d -d -p -r1.120 cpu-exec.c
--- cpu-exec.c	14 Oct 2007 07:07:04 -	1.120
+++ cpu-exec.c	14 Oct 2007 11:35:53 -
@@ -133,6 +133,7 @@ static TranslationBlock *tb_find_slow(ta
 tb->tc_ptr = tc_ptr;
 tb->cs_base = cs_base;
 tb->flags = flags;
+tb->page_addr[0] = phys_page1;
 cpu_gen_code(env, tb, CODE_GEN_MAX_SIZE, &code_gen_size);
 code_gen_ptr = (void *)(((unsigned long)code_gen_ptr + code_gen_size + CODE_GEN_ALIGN - 1) & ~(CODE_GEN_ALIGN - 1));
 
Index: softmmu_header.h
===
RCS file: /sources/qemu/qemu/softmmu_header.h,v
retrieving revision 1.18
diff -u -d -d -p -r1.18 softmmu_header.h
--- softmmu_header.h	14 Oct 2007 07:07:05 -	1.18
+++ softmmu_header.h	14 Oct 2007 11:35:53 -
@@ -289,6 +289,68 @@ static inline void glue(glue(st, SUFFIX)
 }
 }
 
+#else
+
+#if DATA_SIZE <= 2
+static inline RES_TYPE glue(glue(glue(lds,SUFFIX),MEMSUFFIX),_p)(unsigned long *start_pc,
+ unsigned long phys_pc,
+ target_ulong virt_pc)
+{
+RES_TYPE opc;
+
+/* XXX: Target executing code from MMIO ares is not supported for now */
+#if defined(TARGET_HAS_VLE_INSNS) /* || defined(TARGET_MMIO_CODE) */
+if (unlikely((*start_pc ^
+  (phys_pc + sizeof(RES_TYPE) - 1)) >> TARGET_PAGE_BITS)) {
+/* Slow path: phys_pc is not in the same page than start_pc
+ *or the insn is spanning two pages
+ */
+opc = glue(glue(lds,SUFFIX),MEMSUFFIX)(virt_pc);
+/* Avoid softmmu access on next load */
+/* XXX: dont: phys PC is not correct anymore
+ *  We could call get_phys_addr_code(env, pc); and remove the else
+ *  condition, here.
+ */
+//*start_pc = phys_pc;
+} else
+#endif
+{
+opc = glue(glue(lds,SUFFIX),_raw)(phys_pc);
+}
+
+return opc;
+}
+#endif
+
+static inline RES_TYPE glue(glue(glue(ld,USUFFIX),MEMSUFFIX),_p)(unsigned long *start_pc,
+ unsigned long phys_pc,
+ target_ulong virt_pc)
+{
+RES_TYPE opc;
+
+/* XXX: Target executing code from MMIO ares is not supported for now */
+#if defined(TARGET_HAS_VLE_INSNS) /* || defined(TARGET_MMIO_CODE) */
+if (unlikely((*start_pc ^
+  (phys_pc + sizeof(RES_TYPE) - 1)) >> TARGET_PAGE_BITS)) {
+/* Slow path: phys_pc is not in the same page than start_pc
+ *or the insn is spanning two pages
+ */
+opc = glue(glue(ld,USUFFIX),MEMSUFFIX)(virt_pc);
+/* Avoid softmmu access on next load */
+/* XXX: dont: phys PC is not correct anymore
+ *  We could call get_phys_addr_code(env, pc); and remove the else
+ *  condition, here.
+ */
+//*start_pc = phys_pc;
+} else
+#endif
+{
+opc = glue(glue(ld,USUFFIX),_raw)(phys_pc);
+}
+
+return opc;
+}
+
 #endif /* ACCESS_TYPE != (NB_MMU_MODES + 1) */
 
 #endif /* !asm */
Index: target-alpha/translate.c
===
RCS file: /sources/qemu/qemu/target-alpha/translate.c,v
retrieving revision 1.6
diff -u -d -d -p -r1.6 translate.c
--- target-alpha/translate.c	14 Oct 2007 08:50:17 -	1.6
+++ target-alpha/translate.c	14 Oct 2007 11:35:54 -
@@ -1965,6 +1965,7 @@ int gen_intermediate_code_inter

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

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 10:21:20

Modified files:
target-ppc : cpu.h helper.c 

Log message:
Properly implement non-execute bit on PowerPC segments and PTEs.
Fix page protection bits for PowerPC 64 MMU.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.82&r2=1.83
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.79&r2=1.80




Re: [Qemu-devel] qemu alpha?

2007-10-14 Thread J. Mayer
On Sun, 2007-10-14 at 11:19 +0200, Oliver Falk wrote:
> Hi list!

Hi you !

> Just wanted to know how far the progress on alpha target is? I would be
> happy if I have some 'virtual alpha' to test new isos.
> 
> If I can help some way (I have a few alphas around). Let me know.

I'm happy to see someone interresting in improving Alpha support, which
is  very alpha for now !
Current status is alpha-linux-user is able to launch some executable.
Unfortunately, all the one I got crash after some time, probably because
the unique register is not initialized properly. And I got no Alpha
machine to be able to compare what's going wrong in the emulation code.
The softmmu Alpha support is far from being usable for many reasons.
First of all, I started to code a PALcode host-side emulation but it
still needs a lot of work before being usable. The second thing is I
don't really know which CPU model is the best to emulate first and I
don't have the precise specification of the hardware platform to be able
to code the needed hw/alpha.c file.
If you feel like helping developping the Alpha target support, I think
the first target would be to work on the linux-user mode, which mostly
needs debug and bugfixes. Once the core CPU will be validated, the
softmmu suport could be done too.
I can of course help you doing this, if you need advices or support,
having started the target as an invitation for Alpha specialist to make
it really usable.
Then, your help and knowledge is welcome here !

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized





Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

2007-10-14 Thread J. Mayer
On Sun, 2007-10-14 at 11:19 +0300, Blue Swirl wrote:
> On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote:
> > > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote:
> > > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote:
> > > > > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > > > The problem:
> > > > > > > some CPU architectures, namely PowerPC and maybe others, offers
> > > > > > > facilities to access the memory or I/O in the reverse endianness, 
> > > > > > > ie
> > > > > > > little-endian instead of big-endian for PowerPC, or provide 
> > > > > > > instruction
> > > > > > > to make memory accesses in the "reverse-endian". This is 
> > > > > > > implemented as
> > > > > > > a global flag on some CPU. This case is already handled by the 
> > > > > > > PowerPC
> > > > > > > emulation but is is far from being optimal. Some other 
> > > > > > > implementations
> > > > > > > allow the OS to store an "reverse-endian" flag in the TLB or the 
> > > > > > > segment
> > > > > > > descriptors, thus providing per-page or per-segment endianness 
> > > > > > > control.
> > > > > > > This is mostly used to ease driver migration from a PC platform to
> > > > > > > PowerPC without taking any care of the device endianness in the 
> > > > > > > driver
> > > > > > > code (yes, this is bad...).
> > > > > >
> > > > > > Nice, this may be useful for Sparc64. It has a global CPU flag for
> > > > > > endianness, individual pages can be marked as reverse endian, and
> > > > > > finally there are instructions that access memory in reverse endian.
> > > > > > The end result is a XOR of all these reverses. Though I don't know 
> > > > > > if
> > > > > > any of these features are used at all.
> > > > >
> > > > > I realized that I/O accesses for reverse-endian pages were not correct
> > > > > in the softmmu_template.h header. This new version fixes this. It also
> > > > > remove duplicated code in the case of unaligned accesses in a
> > > > > reverse-endian page.
> > > >
> > > > I think 64 bit access case is not handled correctly, but to solve that
> > > > it would be nice to extend the current IO access system to 64 bits.
> > >
> > > I think that if it was previously correct, it should still be, but... I
> > > don't know how much having 64 bits I/O accesses is interresting, as I
> > > don't know if there are real hw buses that have 64 bits data path...
> > >
> > > Here's another version taking care of your remark about ldl memory
> > > accessors.
> > > * I replaced all ldl occurences with ldul
> > > * when TARGET_LONG_BITS == 64, I also added ldsl accessors. And I
> > > started using it in the PowerPC memory access micro-ops.
> > > Then the patch is really more invasive than the previous ones.
> > > This still does not break PowerPC or i386 target, as it seems.
> >
> > Here's a new version. The only change is that, for consistency, I did
> > add the big-endian and little-endian accessors that were documented in
> > cpu-all.h as unimplemented. The implementation is quite trivial, having
> > native and reverse-endian accessors available, and changes functionnally
> > nothing to the previous version.
> 
> The patch does not apply anymore. The Sparc part looks OK.
> 
> The benefits from the patch can be gained by mapping Sparc64 lduw and
> ldsw in op_mem.h  directly to ldul and ldsl using SPARC_LD_OP and
> replacing the ldl+bswap etc. for the LE cases with ldlr in
> op_helper.c. If you prefer, I can do this after you have applied the
> patch.

Yes, there are conflicts between this patch and the mmu_idx one I just
commited. I will regenerate an updated diff in the hours to come, after
I finished commiting the PowerPC fixes and improvments I got waiting in
stock.
For the Sparc improvments, as I merged the PowerPC improvments in the
patch, I think it can be a good idea to include it directly in the
patch.
I'm also wondering if it would not be a good idea to define lduq/ldsq
even if they in fact do exactly what ldq does now, just to have a fully
consistent API.

-- 
J. Mayer <[EMAIL PROTECTED]>
Never organized





[Qemu-devel] qemu/hw ppc.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 09:35:30

Modified files:
hw : ppc.c 

Log message:
Implement time-base start/stop helpers.
Implement PowerPC 6xx time-base enable input pin.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemu&r1=1.33&r2=1.34




[Qemu-devel] qemu/target-ppc cpu.h

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 09:27:16

Modified files:
target-ppc : cpu.h 

Log message:
Merge PowerPC 620 input bus definitions with standard PowerPC 6xx.
Avoid hardcoding PowerPC interrupts definitions to ease updates.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.81&r2=1.82




[Qemu-devel] qemu alpha?

2007-10-14 Thread Oliver Falk
Hi list!

Just wanted to know how far the progress on alpha target is? I would be
happy if I have some 'virtual alpha' to test new isos.

If I can help some way (I have a few alphas around). Let me know.

Best,
 Oliver




[Qemu-devel] qemu/target-ppc cpu.h helper.c translate_init.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 09:14:09

Modified files:
target-ppc : cpu.h helper.c translate_init.c 

Log message:
There is no need of a specific MMU model for PowerPC 601.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.80&r2=1.81
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.78&r2=1.79
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemu&r1=1.50&r2=1.51




[Qemu-devel] qemu/target-ppc helper.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 09:06:19

Modified files:
target-ppc : helper.c 

Log message:
Implement PowerPC 64 SLB invalidation helpers.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.77&r2=1.78




[Qemu-devel] qemu/hw prep_pci.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:52:44

Modified files:
hw : prep_pci.c 

Log message:
Fix memory corruption reported by Julian Seward
  (still more bugs to fix in PreP emulation).

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/prep_pci.c?cvsroot=qemu&r1=1.5&r2=1.6




[Qemu-devel] qemu/target-alpha translate.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:50:17

Modified files:
target-alpha   : translate.c 

Log message:
Allow Alpha target to use supervisor and executive mode micro-ops.

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




[Qemu-devel] qemu hw/ppc.c target-ppc/helper.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:48:24

Modified files:
hw : ppc.c 
target-ppc : helper.c 

Log message:
Do not allow PowerPC CPU restart after entering checkstop mode.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/ppc.c?cvsroot=qemu&r1=1.32&r2=1.33
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.76&r2=1.77




[Qemu-devel] qemu Makefile.target configure

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:38:29

Modified files:
.  : Makefile.target configure 

Log message:
Provision for PowerPC 64 with hypervisor mode support - not enabled for 
now.
For consistency, group all PowerPC targets.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.208&r2=1.209
http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.161&r2=1.162




[Qemu-devel] qemu/target-ppc op.c op_helper.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:27:14

Modified files:
target-ppc : op.c op_helper.c 

Log message:
Generate micro-ops for PowerPC hypervisor mode.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.55&r2=1.56
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.50&r2=1.51




Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

2007-10-14 Thread Blue Swirl
On 10/14/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote:
> > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote:
> > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote:
> > > > > On 10/13/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> > > > > > The problem:
> > > > > > some CPU architectures, namely PowerPC and maybe others, offers
> > > > > > facilities to access the memory or I/O in the reverse endianness, ie
> > > > > > little-endian instead of big-endian for PowerPC, or provide 
> > > > > > instruction
> > > > > > to make memory accesses in the "reverse-endian". This is 
> > > > > > implemented as
> > > > > > a global flag on some CPU. This case is already handled by the 
> > > > > > PowerPC
> > > > > > emulation but is is far from being optimal. Some other 
> > > > > > implementations
> > > > > > allow the OS to store an "reverse-endian" flag in the TLB or the 
> > > > > > segment
> > > > > > descriptors, thus providing per-page or per-segment endianness 
> > > > > > control.
> > > > > > This is mostly used to ease driver migration from a PC platform to
> > > > > > PowerPC without taking any care of the device endianness in the 
> > > > > > driver
> > > > > > code (yes, this is bad...).
> > > > >
> > > > > Nice, this may be useful for Sparc64. It has a global CPU flag for
> > > > > endianness, individual pages can be marked as reverse endian, and
> > > > > finally there are instructions that access memory in reverse endian.
> > > > > The end result is a XOR of all these reverses. Though I don't know if
> > > > > any of these features are used at all.
> > > >
> > > > I realized that I/O accesses for reverse-endian pages were not correct
> > > > in the softmmu_template.h header. This new version fixes this. It also
> > > > remove duplicated code in the case of unaligned accesses in a
> > > > reverse-endian page.
> > >
> > > I think 64 bit access case is not handled correctly, but to solve that
> > > it would be nice to extend the current IO access system to 64 bits.
> >
> > I think that if it was previously correct, it should still be, but... I
> > don't know how much having 64 bits I/O accesses is interresting, as I
> > don't know if there are real hw buses that have 64 bits data path...
> >
> > Here's another version taking care of your remark about ldl memory
> > accessors.
> > * I replaced all ldl occurences with ldul
> > * when TARGET_LONG_BITS == 64, I also added ldsl accessors. And I
> > started using it in the PowerPC memory access micro-ops.
> > Then the patch is really more invasive than the previous ones.
> > This still does not break PowerPC or i386 target, as it seems.
>
> Here's a new version. The only change is that, for consistency, I did
> add the big-endian and little-endian accessors that were documented in
> cpu-all.h as unimplemented. The implementation is quite trivial, having
> native and reverse-endian accessors available, and changes functionnally
> nothing to the previous version.

The patch does not apply anymore. The Sparc part looks OK.

The benefits from the patch can be gained by mapping Sparc64 lduw and
ldsw in op_mem.h  directly to ldul and ldsl using SPARC_LD_OP and
replacing the ldl+bswap etc. for the LE cases with ldlr in
op_helper.c. If you prefer, I can do this after you have applied the
patch.




[Qemu-devel] qemu/target-alpha op.c op_helper.c

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 08:18:12

Modified files:
target-alpha   : op.c op_helper.c 

Log message:
Generate micro-ops for Alpha executive and supervisor modes.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op.c?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op_helper.c?cvsroot=qemu&r1=1.3&r2=1.4




Re: [Qemu-devel] [RFC] sparc32 MXCC support

2007-10-14 Thread Blue Swirl
On 10/13/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> I'm trying to add SuperSparc II MXCC support and need some feedback.
>
> Is there a better way to read and write physical memory in 64bit chunks?
> I'm not sure what I'm doing is portable between 32/64 and big/little endian.

Thank you for your effort. Applying the patch allows NetBSD on SS-10
to boot as far as on SS-5, previously it crashed.

I think the code is portable, but I think changing the register type
to uint32_t and using a DPRINTF system like used in for example
hw/iommu.c should make the code slightly clearer.

For the memory access, ldl/q_phys/stl/q_phys is used in other block
copy routines. For longer blocks or if the address can be unaligned,
cpu_physical_memory_read() could be a better choice.

> +int cpu_sparc_register (CPUSPARCState *env, const sparc_def_t *def, int cpu);

unsigned int cpu?

> +printf("ERROR: helper_ld_asi(asi = %d, size = %d, sign = %d) 
> T0 = %08x: unsupported size\n", asi, size, sign, T0);

If it's an error to access the registers with different size, you
should use do_unassigned_access() to report this.




[Qemu-devel] qemu cpu-defs.h cpu-exec.c exec-all.h exec.c so...

2007-10-14 Thread Jocelyn Mayer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer  07/10/14 07:07:08

Modified files:
.  : cpu-defs.h cpu-exec.c exec-all.h exec.c 
 softmmu_exec.h softmmu_header.h 
 softmmu_template.h 
hw : alpha_palcode.c 
target-alpha   : cpu.h exec.h helper.c op_helper.c 
target-arm : cpu.h exec.h helper.c op_helper.c 
target-cris: cpu.h exec.h helper.c mmu.c mmu.h op_helper.c 
target-i386: cpu.h exec.h helper.c helper2.c 
target-m68k: cpu.h exec.h helper.c op_helper.c 
target-mips: cpu.h exec.h helper.c op_helper.c 
target-ppc : cpu.h exec.h helper.c op_helper.c translate.c 
target-sh4 : cpu.h exec.h helper.c op_helper.c 
target-sparc   : cpu.h exec.h helper.c op_helper.c translate.c 

Log message:
Replace is_user variable with mmu_idx in softmmu core,
  allowing support of more than 2 mmu access modes.
Add backward compatibility is_user variable in targets code when needed.
Implement per target cpu_mmu_index function, avoiding duplicated code
  and #ifdef TARGET_xxx in softmmu core functions.
Implement per target mmu modes definitions. As an example, add PowerPC
  hypervisor mode definition and Alpha executive and kernel modes 
definitions.
Optimize PowerPC case, precomputing mmu_idx when MSR register changes
  and using the same definition in code translation code.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemu&r1=1.24&r2=1.25
http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.119&r2=1.120
http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.67&r2=1.68
http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.108&r2=1.109
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_exec.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemu&r1=1.17&r2=1.18
http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemu&r1=1.18&r2=1.19
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/alpha_palcode.c?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/cpu.h?cvsroot=qemu&r1=1.8&r2=1.9
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/exec.h?cvsroot=qemu&r1=1.3&r2=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/helper.c?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op_helper.c?cvsroot=qemu&r1=1.2&r2=1.3
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/cpu.h?cvsroot=qemu&r1=1.35&r2=1.36
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/exec.h?cvsroot=qemu&r1=1.13&r2=1.14
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/helper.c?cvsroot=qemu&r1=1.22&r2=1.23
http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_helper.c?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/cpu.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/exec.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/helper.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/mmu.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/mmu.h?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/op_helper.c?cvsroot=qemu&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemu&r1=1.50&r2=1.51
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemu&r1=1.37&r2=1.38
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.89&r2=1.90
http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemu&r1=1.52&r2=1.53
http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/cpu.h?cvsroot=qemu&r1=1.13&r2=1.14
http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/exec.h?cvsroot=qemu&r1=1.4&r2=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/helper.c?cvsroot=qemu&r1=1.7&r2=1.8
http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op_helper.c?cvsroot=qemu&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemu&r1=1.48&r2=1.49
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemu&r1=1.38&r2=1.39
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemu&r1=1.54&r2=1.55
http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemu&r1=1.65&r2=1.66
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemu&r1=1.79&r2=1.80
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/exec.h?cvsroot=qemu&r1=1.28&r2=1.29
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemu&r1=1.75&r2=1.76
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemu&r1=1.49&r2=1.50
http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot