- 04 Feb, 2008 40 commits
-
-
Thomas Gleixner authored
Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Ingo Molnar authored
Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
[ tglx@linutronix.de: fix bootup crash on sparse mappings. ] Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
a PUD entry covers 1GB of virtual memory. Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
Use set_pte() for setting up the 2MB pages in the direct mapping. Signed-off-by:
-
Thomas Gleixner authored
pte_present() might return true for PROT_NONE mappings. Explicitely check the present bit. Signed-off-by:
-
Ingo Molnar authored
this race is legit and can happen on SMP systems. Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Andi Kleen authored
pci-gart needs to unmap the IOMMU aperture to prevent cache corruptions. Switch this over to using set_memory_np() instead of clear_kernel_mapping(). Signed-off-by:
-
Thomas Gleixner authored
pud and pmd entries in the RAM area might be marked as non present. Do not try to modify them in the selftest. Signed-off-by:
-
Thomas Gleixner authored
Move the readout of the large entry into the spinlock section to prevent an unlikely but possible race. Mark the pmd/pud entry present after the split. We preserved the non present bit in the new split mapping. Remove the stale gfp_flags double initialization. Signed-off-by:
-
Andi Kleen authored
Fix up all users. Signed-off-by:
-
Thomas Gleixner authored
lookup_address() returns a wrong level and a wrong pointer to a non existing pte, when pmd or pud entries are marked !present. This happens for example due to boot time mapping of GART into the low memory space. Signed-off-by:
-
Ingo Molnar authored
An Athlon 64 X2 test system showed hard hangs shortly after marking the kernel text read-only, if we tried to preserve largepages and changed the PSE entry from RW to RO. The pagetable code itself is correct, it's the CPU that locked up hard (and not even the NMI watchdog could punch through that hard hang). So be conservative and always do splitups - like we did in the past. Signed-off-by: -
Thomas Gleixner authored
When CPA is called on a range which fits into a large page mapping, avoid to split the page when: 1) There is no change of attributes 2) The range to change is a complete large mapping Signed-off-by:
-
Thomas Gleixner authored
Flush tlbs only when there was a real change. Signed-off-by:
-
Thomas Gleixner authored
The number of arguments which need to be transported is increasing and we want to add flush optimizations and large page preserving. Create struct cpa data and pass a pointer instead of increasing the number of arguments further. Signed-off-by:
-
Andi Kleen authored
We only need to flush the caches in cpa() if the the caching attributes have changed. Otherwise only flush the TLBs. This checks the PAT bits too although they are currently not used by the kernel. Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Thomas Gleixner authored
Mask out the not supported bits (e.g. NX). If the clr/set masks are empty after the mask return without changing anything. Signed-off-by:
-
Huang, Ying authored
The patch updates EFI runtime memory mapping code, by making EFI areas explicitly executable. Signed-off-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
-
Thomas Gleixner authored
When an ioremap is unmapped, do not change the page attributes. There might be another mapping of the same physical address. PAT might detect a conflicting mapping attribute for no good reason. The mapping is removed anyway. Signed-off-by:
-
Thomas Gleixner authored
Now that cpa works on non-direct mappings as well, we can safely remove the range check in ioremap_change_attr(). Signed-off-by:
-
Thomas Gleixner authored
Remove tons of castings which make the code hard to read. Signed-off-by:
-
Thomas Gleixner authored
When splitting large pages, we ge the pfn from the existing entry instead of calculating it ourself. This removes the last remaining range restriction of the cpa code. Signed-off-by:
-
Arjan van de Ven authored
When changing the attributes of a pte, we should use the PFN from the existing PTE rather than going through hoops calculating what we think it might have been; this is both fragile and totally unneeded. It also makes it more hairy to call any of these functions on non-direct maps for no good reason whatsover. With this change, __change_page_attr() no longer takes a pfn as argument, which simplifies all the callers. Signed-off-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@tglx.de>
-
Arjan van de Ven authored
Right now, enforcing that the high mapping of the kernel text doesn't get the NX bit is done deep in the guts of CPA, rather than in the static_protection() function that enforces all other per-arch sanity checks. This patch moves this sanity check into the central static_protection() function instead, and makes it apply ONLY to the kernel text, not to all other areas in the high mapping. Signed-off-by:
-
Harvey Harrison authored
mtrr.h was included everywhere needed. Fixes the following sparse warnings. Also, the return types in the extern definitions were incorrect. arch/x86/kernel/cpu/mtrr/amd.c:113:12: warning: symbol 'amd_init_mtrr' was not declared. Should it be static? arch/x86/kernel/cpu/mtrr/cyrix.c:268:12: warning: symbol 'cyrix_init_mtrr' was not declared. Should it be static? arch/x86/kernel/cpu/mtrr/centaur.c:218:12: warning: symbol 'centaur_init_mtrr' was not declared. Should it be static? Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
cpu.h was already included everywhere needed. Fixes following sparse warnings: arch/x86/kernel/cpu/amd.c:343:12: warning: symbol 'amd_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/cyrix.c:444:12: warning: symbol 'cyrix_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/cyrix.c:456:12: warning: symbol 'nsc_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/centaur.c:467:12: warning: symbol 'centaur_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/transmeta.c:112:12: warning: symbol 'transmeta_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/intel.c:296:12: warning: symbol 'intel_cpu_init' was not declared. Should it be static? arch/x86/kernel/cpu/nexgen.c:56:12: warning: symbol 'nexgen_init_cpu' was not declared. Should it be static? arch/x86/kernel/cpu/umc.c:22:12: warning: symbol 'umc_init_cpu' was not declared. Should it be static? Signed-off-by:
-
Harvey Harrison authored
arch/x86/kernel/process_32.c:254:43: warning: Using plain integer as NULL pointer Signed-off-by:
-
Harvey Harrison authored
Global functions should include their prototypes. Signed-off-by:
-
Harvey Harrison authored
Fixes sparse warning: arch/x86/kernel/cpu/intel.c:48:15: warning: symbol 'ppro_with_ram_bug' was not declared. Should it be static? Signed-off-by:
-
Harvey Harrison authored
A few snuck back in to x86. Signed-off-by:
-
Andi Kleen authored
Now that the only user does it on its own remove the NUMAQ support macros in io_32.h The next step would be to convert the preprocessor mess to actually readable standard inlines. Signed-off-by:
-
