history/include/asm-x86_64, branch master

merge

2005-04-01T04:36:30Z

[PATCH] consolidate asm/ipc.h

2005-03-31T00:38:00Z

All the asm*/ipc.h files are basically the same (for things that are used) so I have consolidated them all into asm-generic/ipc.h Signed-off-by: Stephen Rothwell Acked-By: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86, x86_64: reading deterministic cache parameters and exporting it in /sysfs

2005-03-31T00:34:11Z

The attached patch adds support for using cpuid(4) instead of cpuid(2), to get CPU cache information in a deterministic way for Intel CPUs, whenever supported. The details of cpuid(4) can be found here IA-32 Intel Architecture Software Developer's Manual (vol 2a) (http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a) and Prescott New Instructions (PNI) Technology: Software Developer's Guide (http://www.intel.com/cd/ids/developer/asmo-na/eng/events/43988.htm) The advantage of using the cpuid(4) ('Deterministic Cache Parameters Leaf') are: - It provides more information than the descriptors provided by cpuid(2) - It is not table based as cpuid(2). So, we will not need changes to the kernel to support new cache descriptors in the descriptor table (as is the case with cpuid(2)). The patch also adds a bunch of interfaces under /sys/devices/system/cpu/cpuX/cache, showing various information about the caches. Most useful field being shared_cpu_map, which says what caches are shared among which logical cpus. The patch adds support for both i386 and x86-64. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] seccomp for ppc64

2005-03-31T00:31:40Z

This patch against 12-rc1 adds seccomp to the ppc64 arch. I tested it successfully with the seccomp_test. I didn't bother to change the syscall exit not to check for TIF_SECCOMP, in theory that bit could be optimized but it's an optimization in the slow path, and current code is a bit simpler. I also verified it still compiles and works fine on x86 and x86-64. Instead of the TIF_32BIT redefine, if you want to change x86-64 to use TIF_32BIT too (instead of TIF_IA32), let me know. Signed-off-by: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] io_remap_pfn_range: add for all arch-es

2005-03-28T12:01:12Z

This patch introduces a new interface function for mapping bus/device memory: io_remap_pfn_range. This accepts the same parameters as remap_pfn_range and io_remap_page_range but should be used in any situation where the caller is not simply remapping ordinary RAM. For example, when mapping device registers the new function should be used. The distinction between remapping device memory and ordinary RAM is critical for the Xen hypervisor. This patch series also cleans up the remaining users of io_remap_page_range (in particular, the several sparc-specific sections in various drivers that use a special form of io_remap_page_range: an extra argument for SPARC arch.) by converting them to use io_remap_pfn_range(), where io_remap_pfn_range() supports passing as part of the pfn argument. The sparc32 & sparc64 code needs live testing. (from Keir:) I have audited the drivers/ and sound/ directories. Most uses of remap_pfn_range are okay, but there are a small handful that are remapping device memory (mostly AGP and DRM drivers). Of particular driver is the HPET driver, whose mmap function is broken even for native (non-Xen) builds. If nothing else, vmalloc_to_phys should be used instead of __pa to convert an ioremapped virtual address to a valid physical address. The fix in this patch is to remember the original bus address as probed at boot time and to pass this to io_remap_pfn_range. io_remap_pfn_range(): add io_remap_pfn_range() for all arches; add MK_IOSPACE_PFN(), GET_IOSPACE(), and GET_PFN() for all arches but primarily for sparc32/64's extended IO space, sparc: kill the hack of using low bit of to mean write_combine or set side-effect (_PAGE_E) bit; (DaveM suggested that I kill it;) future: convert remaining callers of io_remap_page_range() to io_remap_pfn_range() and deprecate io_remap_page_range(); Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86_64: remove old decl (trivial)

2005-03-28T11:40:59Z

vm_force_exec32 and friends were still alive on 2.6.9 release, but now (and in 2.6.10) they seem deleted. Signed-off-by: Paolo 'Blaisorblade' Giarrusso Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86_64: Only free PMDs and PUDs after other CPUs have been flushed

2005-03-28T11:38:32Z

This avoids a race on AMD systems where other CPUs could speculatively follow an already freed page table. Signed-off-by: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86_64: Fix LDT descriptor

2005-03-28T11:37:59Z

Fix bug introduced with the TLS system calls in 2.5. The LDT descriptor needs two entries, not one. It would overlap into the TLS range, which means setting an LDT would corrupt the first TLS descriptor. Noticed by Jan Beulich Signed-off-by: Andi Kleen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86_64: Always reload CR3 completely when a lazy MM thread drops a MM.

2005-03-28T11:37:42Z

Always reload CR3 completely when a lazy MM thread drops a MM. This avoids keeping stale mappings around in the TLB that could be run into by the CPU by itself (e.g. during prefetches). Signed-off-by: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] x86_64: Work around Tyan BIOS MTRR initialization bug.

2005-03-28T11:35:15Z

Work around Tyan BIOS MTRR initialization bug. Some Tyan AMD BIOS don't initialize the first fixed range MTRR, which causes it to contain random bogus values. When the MTRR tries to duplicate the MTRR state to other CPUs at startup it oopses because of this. This patch works around this by catching exception while setting MTRRs. It would be better to validate all fixed range MTRRs and fix them, but that would be very complicated code. This simple hack seems to work too (except that the first 64k of physical memory are likely uncached). A BIOS update fixes that. Signed-off-by: Andi Kleen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds