Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
On Wed, Dec 22, 2010 at 06:13:37AM +, Matt Thomas wrote: Log Message: Rework how fixups are processed. Inside of generating a table, we just scan kernel text for jumps to locations between (__stub_start, __stub_end] and if found, we actually decode the instructions in the stub to find out where the stub would eventually jump to and then patch the original jump to jump directly to it bypassing the stub. This is slightly slower than the previous method but it's a simplier and new stubs get automagically handled. Isn't this a bit dangerous if anything other than code ends up in the kernel text ? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips
Hi Cliff, A couple of things with these changes: Module Name:src Committed By: cliff Date: Thu Jun 10 00:32:11 UTC 2010 Modified Files: src/sys/arch/mips/include [matt-nb5-mips64]: locore.h Log Message: - add lsw_bus_error to struct locoresw, provides hook to call for chip-specific bus error handling/decode from e.g. trap() and Module Name: src Committed By: cliff Date: Thu Jun 10 00:33:51 UTC 2010 Modified Files: src/sys/arch/mips/mips [matt-nb5-mips64]: trap.c Log Message: - in trap(), if traptype is bus error, call chip-specific bus error handler in locoresw: (*mips_locoresw.lsw_bus_error)(cause) 1: It's not obvious to me if you're trying to provide for a replacement bus error handler (as the commit seems to imply) or an assistant to the current bus error handler (which is what the code does). 2: With: if ((TRAPTYPE(cause) == 6) || (TRAPTYPE(cause) == 7)) (void)(*mips_locoresw.lsw_bus_error)(cause); please please avoid magic numbers - the intent of this isn't obvious at all. 3: It appears that only sbmips actually sets the lsw_bus_error handler, so a bus error on any other arch would NULL-deference and panic? 4: With: #ifdef MIPS3_PLUS #define TRAPTYPE(x) (((x) MIPS3_CR_EXC_CODE) MIPS_CR_EXC_CODE_SHIFT) #else #define TRAPTYPE(x) (((x) MIPS1_CR_EXC_CODE) MIPS_CR_EXC_CODE_SHIFT) #endif This looks like it assumes MIPS1 or MIPS3+ at compile time, but we can have one kernel that can run on both. This needs to be a runtime thing. Maybe create a macro/inline function to extract the EXC part of a cause reg in mips/include/cpureg.h too? 5: Is this worth generalising? Someone might want to add other CPU specific trap error handlers so it might be better doing something like: if (mips_locoresw.lsw_trap_error) (void)(*mips_locoresw.lsw_trap_error)(status, cause, vaddr, opc); and letting the handler determine which exception codes to deal with. This isn't in time critical code (it either panics or drops to ddb/kgdb) to the if () check doesn't hurt. This would also fix 3 above. Cheers, Simon.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
Matt Thomas wrote: Module Name: src Committed By: matt Date: Tue May 11 21:51:34 UTC 2010 Modified Files: src/sys/arch/mips/include [matt-nb5-mips64]: locore.h Log Message: Need to turn KX for N32 kernels with mips3_lw_a64 and mips3_sw_a64 +#elif defined(__mips_n32) + uint32_t sr = mips_cp0_status_read(); + mips_cp0_status_write((sr ~MIPS_SR_INT_IE) | MIPS3_SR_KX); + rv = *(const uint32_t *)addr; Erm, doesn't that cast toss away the high 32-bits of the address you're try to load/store from/to? Cheers, Simon.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
Matt Thomas wrote: Module Name: src Committed By: matt Date: Tue May 11 22:08:02 UTC 2010 Modified Files: src/sys/arch/mips/include [matt-nb5-mips64]: locore.h Log Message: Use assembly since deref a 64bit value as a pointer does not make a 32bit compiler happy. Dang, ignore my previous because this code is a little different. + __asm volatile(lw %0, 0(%1) : =r(rv) : d(addr)); d is listed as General-purpose integer register in the gcc docs. Does the new code pass the full 64-bits of addr in when compiled on an ABI where an int is 32-bits even though a full register is 64-bits? Cheers, Simon.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
On May 12, 2010, at 5:19 AM, Simon Burge wrote: Matt Thomas wrote: Module Name: src Committed By:matt Date:Tue May 11 22:08:02 UTC 2010 Modified Files: src/sys/arch/mips/include [matt-nb5-mips64]: locore.h Log Message: Use assembly since deref a 64bit value as a pointer does not make a 32bit compiler happy. Dang, ignore my previous because this code is a little different. + __asm volatile(lw %0, 0(%1) : =r(rv) : d(addr)); d is listed as General-purpose integer register in the gcc docs. Does the new code pass the full 64-bits of addr in when compiled on an ABI where an int is 32-bits even though a full register is 64-bits? Yes.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips
On May 4, 2010, at 5:30 PM, Simon Burge wrote: Matt Thomas wrote: Modified Files: src/sys/arch/mips/mips [matt-nb5-mips64]: pmap_segtab.c Log Message: Cleanup segtab allocation. Add some counters to monitor memory usage. +uint32_t nget_segtab; +uint32_t nput_segtab; +uint32_t npage_segtab; How quickly could these wrap? Not very and they are really intended for short use. 4B lwp creations :) I'm not worried about wrapping.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
On Thu, Feb 25, 2010 at 05:53:23AM +, Matt Thomas wrote: Log Message: Make the UP and MP ASID allocation algorithm common. Significantly improve the algorithm. Now when we exhaust the ASIDs, interrogate the TLB for active ASIDS and release all the other for future allocations. This leaves the TLB entries with ASIDs valid avoiding the need to re-incur TLB misses for them. I presume it is willing to kill some TLB entries if the above doesn't find any (or enough) free ASIDs ? Or is the ASID number space guaranteed to be significantly higher that the number of TLBs ?? David -- David Laight: da...@l8s.co.uk
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
On Feb 24, 2010, at 10:31 PM, David Laight wrote: On Thu, Feb 25, 2010 at 05:53:23AM +, Matt Thomas wrote: Log Message: Make the UP and MP ASID allocation algorithm common. Significantly improve the algorithm. Now when we exhaust the ASIDs, interrogate the TLB for active ASIDS and release all the other for future allocations. This leaves the TLB entries with ASIDs valid avoiding the need to re-incur TLB misses for them. I presume it is willing to kill some TLB entries if the above doesn't find any (or enough) free ASIDs ? Or is the ASID number space guaranteed to be significantly higher that the number of TLBs ?? If it can't reclaim at least half of the ASID space, it invalidates all ASID based entries in the TLB. And for MIPS32/MIPS64 the ASID space is at least 4x the number of TLB entries.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
Matt Thomas wrote: Module Name: src Committed By: matt Date: Fri Feb 5 07:36:51 UTC 2010 [ ... ] Add __HAVE_FAST_SOFTINTS support. Add routine to remap an uarea via a direct-mapped address. This avoids TLB machinations when swtching to/from the softint thread. This can only be done for lwp which won't exit. Is this printf in cpu_uarea_remap() meant to be there? + printf(ctx=%#PRIxVADDR utf=%p\n, + (vaddr_t)l-l_addr-u_pcb.pcb_context.val[_L_SP], + l-l_md.md_utf Cheers, Simon.
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
On Sun, Jan 31, 2010 at 01:33:59AM +, David Holland wrote: gcc does not seem to be very deterministic about this kind of thing. I've being trying to stop gcc using too many registers in another project - with 24 available registers you'd think it would manage not to spill locals to the stack! But no, the 'status function' (which just copies info into a big buffer with a few local actions) managed to generate temporaries all of its own! In this case marking the target buffer 'volatile' helped no end! David -- David Laight: da...@l8s.co.uk
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
David A. Holland said; Change MIPS_CURLWP from s7 to t8. ... Huh. That surprises me slightly. Good to know though. Remember to bump the kernel version when you merge the branch, or anyone using modules will get a nasty surprise :-) It's a major incompatiblity to change MIPS label_t definition (for pcb-pcb_context), which I hesitate to accept. Yes, a large caution (for NetBSD mips people) is required before branch merge. Toru Nishimura / ALKYL Technology
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips
On Sat, Jan 30, 2010 at 11:49:31PM +, Matt Thomas wrote: Change MIPS_CURLWP from s7 to t8. In a MALTA64 kernel, s6 is used 9155 times which means the compiler could really use s7 is was free to do so. The least used temporary was t8 (288 times). Once the kernel was switched to use t8 for MIPS_CURLWP, s7 was used 7524 times. Huh. That surprises me slightly. Good to know though. Remember to bump the kernel version when you merge the branch, or anyone using modules will get a nasty surprise :-) [For some reason, pre-change t1 was never used and post change t2 was never used. Not sure why.] gcc does not seem to be very deterministic about this kind of thing. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips
[wrong list, redirecting to source-changes-d, sorry...] On Wed, Nov 18, 2009 at 10:34:54AM +0100, Martin Husemann wrote: On Tue, Nov 17, 2009 at 07:56:27AM +, Matt Thomas wrote: (slightly bogus but then we really should kill extent and switch to vmem) I keep hearing this mantra. Yet I don't see how vmem(9) is up to the task of, say, managing pcmcia io port allocations (without bogusly wasting memory). Why is the vmem interface preferable? I see how we could improve the extend(9) implementation (e.g. kill the use fo malloc()). Martin
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips
@@ -876,10 +876,17 @@ moves2, t2 # stash most of temporary regs REG_S t3, FRAME_T3(k1)# syscall saved gp for fork mfc0a1, MIPS_COP_0_STATUS # 2nd arg is STATUS +#if defined(__mips_n32) || defined(__mips_n64) + REG_S a4, FRAME_A4(k1) + REG_S a5, FRAME_A5(k1) + REG_S a6, FRAME_A6(k1) + REG_S a7, FRAME_A7(k1) +#else moves4, ta0 moves5, ta1 moves6, ta2 moves7, ta3 +#endif #REG_S t8, FRAME_T8(k1) #REG_S t9, FRAME_T9(k1) REG_S gp, FRAME_GP(k1) This should be #if !defined(__mips_o32) ... #else ... #endif. Otherwise O64 kernel + N32/N64 userland won't work. Masao
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips
On Sep 2, 2009, at 4:41 PM, Masao Uebayashi wrote: @@ -876,10 +876,17 @@ moves2, t2 # stash most of temporary regs REG_S t3, FRAME_T3(k1)# syscall saved gp for fork mfc0a1, MIPS_COP_0_STATUS # 2nd arg is STATUS +#if defined(__mips_n32) || defined(__mips_n64) + REG_S a4, FRAME_A4(k1) + REG_S a5, FRAME_A5(k1) + REG_S a6, FRAME_A6(k1) + REG_S a7, FRAME_A7(k1) +#else moves4, ta0 moves5, ta1 moves6, ta2 moves7, ta3 +#endif #REG_S t8, FRAME_T8(k1) #REG_S t9, FRAME_T9(k1) REG_S gp, FRAME_GP(k1) This should be #if !defined(__mips_o32) ... #else ... #endif. Otherwise O64 kernel + N32/N64 userland won't work. O64 kernel? why should we worry about O64?
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Fri Aug 21 17:29:42 UTC 2009
Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h
Log Message:
Adapt to ABI variations. Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.
What's the point of having both? Why not just register_t and be done
with it
To generate a diff of this commit:
cvs rdiff -u -r1.43.36.1 -r1.43.36.2 src/sys/arch/mips/include/types.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
-- thorpej
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
On Aug 22, 2009, at 4:30 PM, Matt Thomas wrote:
On Aug 22, 2009, at 4:25 PM, Jason Thorpe wrote:
On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Fri Aug 21 17:29:42 UTC 2009
Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h
Log Message:
Adapt to ABI variations. Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.
What's the point of having both? Why not just register_t and be
done with it
Mostly to avoid casting. If it's X, use PRIxX and don't worry.
No, what's the point of having mips_reg_t ???
-- thorpej
