Re: [Qemu-devel] RFC: Code fetch optimisation
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
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
> 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?
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
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
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
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
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
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
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...
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...
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 ...
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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...
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