aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc/mm/init_64.c
AgeCommit message (Collapse)Author
2009-08-25sparc64: Validate linear D-TLB misses.David S. Miller
When page alloc debugging is not enabled, we essentially accept any virtual address for linear kernel TLB misses. But with kgdb, kernel address probing, and other facilities we can try to access arbitrary crap. So, make sure the address we miss on will translate to physical memory that actually exists. In order to make this work we have to embed the valid address bitmap into the kernel image. And in order to make that less expensive we make an adjustment, in that the max physical memory address is decreased to "1 << 41", even on the chips that support a 42-bit physical address space. We can do this because bit 41 indicates "I/O space" and thus covers non-memory ranges. The result of this is that: 1) kpte_linear_bitmap shrinks from 2K to 1K in size 2) we need 64K more for the valid address bitmap We can't let the valid address bitmap be dynamically allocated once we start using it to validate TLB misses, otherwise we have crazy issues to deal with wrt. recursive TLB misses and such. If we're in a TLB miss it could be the deepest trap level that's legal inside of the cpu. So if we TLB miss referencing the bitmap, the cpu will be out of trap levels and enter RED state. To guard against out-of-range accesses to the bitmap, we have to check to make sure no bits in the physical address above bit 40 are set. We could export and use last_valid_pfn for this check, but that's just an unnecessary extra memory reference. On the plus side of all this, since we load all of these translations into the special 4MB mapping TSB, and we check the TSB first for TLB misses, there should be absolutely no real cost for these new checks in the TLB miss path. Reported-by: heyongli@gmail.com Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-18sparc64: Fix UP bootup regression.David S. Miller
Commit b696fdc259f0d94348a9327bed352fac44d4883d ("sparc64: Defer cpu_data() setup until end of per-cpu data initialization.") broke bootup for UP builds because the cpu_data() initialization only occurs in setup_per_cpu_areas() which is never compiled in nor called in UP builds. Fix this up by calling the setups directly from init_64.c when non-SMP. Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Tested-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-16sparc: replace uses of CPU_MASK_ALL_PTRStephen Rothwell
CPU_MASK_ALL is the (deprecated) "all bits set" cpumask, defined as so: #define CPU_MASK_ALL (cpumask_t) { { ... } } Taking the address of such a temporary is questionable at best, unfortunately 321a8e9d (cpumask: add CPU_MASK_ALL_PTR macro) added CPU_MASK_ALL_PTR: #define CPU_MASK_ALL_PTR (&CPU_MASK_ALL) Which formalizes this practice. One day gcc could bite us over this usage (though we seem to have gotten away with it so far). [Description by Rusty Russell] Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-16sparc64: Get rid of real_setup_per_cpu_areas().David S. Miller
Now that we defer the cpu_data() initializations to the end of per-cpu setup, we can get rid of this local hack we had to setup the per-cpu areas eary. This is a necessary step in order to support HAVE_DYNAMIC_PER_CPU_AREA since the per-cpu setup must run when page structs are available. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-16sparc64: Defer cpu_data() setup until end of per-cpu data initialization.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-16sparc64: Make mdesc_fill_in_cpu_data take a cpumask_t pointer.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-06-16sparc: Call OF and MD cpu scanning explicitly from paging_init()David S. Miller
We need to split up the cpu present mask setup from the cpu_data initialization, and this is a first step towards that. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-04-08sparc64: add_node_ranges() must be __initDavid S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-04-08sparc64: Fix section mismatch warnings in PCI controller drivers.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-16cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: ↵Rusty Russell
sparc64 Impact: cleanup, futureproof In fact, all cpumask ops will only be valid (in general) for bit numbers < nr_cpu_ids. So use that instead of NR_CPUS in various places. This is always safe: no cpu number can be >= nr_cpu_ids, and nr_cpu_ids is initialized to NR_CPUS at boot. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Ingo Molnar <mingo@elte.hu>
2009-01-08sparc64: move EXPORT_SYMBOL to the symbols definitionSam Ravnborg
Move all applicable EXPORT_SYMBOL()s to the file where the respective symbol is defined. Removed all the includes that are no longer needed in sparc_ksyms_64.c Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_64.c Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Additions by Julian Calaby: * Moved EXPORT_SYMBOL()s for prom functions to their rightful places. * Made some minor cleanups to the includes and comments of sparc_ksyms_64.c * Updated and tidied commit message. * Rebased patch over sparc-2.6.git HEAD. * Ensured that all modified files have the correct includes. Signed-off-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-06sparc64: Use unsigned long long for u64.Sam Ravnborg
Andrew Morton wrote: People keep on doing printk("%llu", some_u64); testing it only on x86_64 and this generates a warning storm on powerpc, sparc64, etc. Because they use `long', not `long long'. Quite a few 64-bit architectures are using `long' for their s64/u64 types. We should convert them all to `long long'. Update types.h so we use unsigned long long for u64 and fix all warnings in sparc64 code. Tested with an allnoconfig, defconfig and allmodconfig builds. This patch introduces additional warnings in several drivers. These will be dealt with in separate patches. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-06sparc64: refactor code in init_64.cSam Ravnborg
The sparc64 allmodconfig build broke due to enabling of the branch_tracer that does some very clever things with all if conditions. This caused my gcc 3.4.5 to be so confused that it emitted two warnings: arch/sparc/mm/init_64.c: In function `update_mmu_cache': arch/sparc/mm/init_64.c:271: warning: 'pg_flags' might be used uninitialized in this function arch/sparc/mm/init_64.c:272: warning: 'page' might be used uninitialized in this function And with -Werror this broke the build. Refactor code so it: 1) becomes more readable 2) no longer emit a warning with the branch_tracer enabled The refactoring uses a small helper function (flush_dcache()). Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-12-04sparc,sparc64: unify mm/Sam Ravnborg
- move all sparc64/mm/ files to arch/sparc/mm/ - commonly named files are named _64.c - add files to sparc/mm/Makefile preserving link order - delete now unused sparc64/mm/Makefile - sparc64 now finds mm/ in sparc Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>