linux.git/include/asm-x86, branch v2.6.26-rc7 Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git x86, geode: add a VSA2 ID for General Software 2008-06-19T12:19:03+00:00 Jordan Crouse jordan.crouse@amd.com 2008-06-18T17:34:38+00:00 ffe6e1da86d21d7855495b5a772c93f050258f6e General Software writes their own VSA2 module for their version of the Geode BIOS, which returns a different ID then the standard VSA2. This was causing the framebuffer driver to break for most GSW boards. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Cc: tglx@linutronix.de Cc: linux-geode@lists.infradead.org Signed-off-by: Ingo Molnar <mingo@elte.hu> 
General Software writes their own VSA2 module for their version
of the Geode BIOS, which returns a different ID then the standard
VSA2.  This was causing the framebuffer driver to break for most
GSW boards.

Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
Cc: tglx@linutronix.de
Cc: linux-geode@lists.infradead.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits. 2008-06-19T08:08:44+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-06-06T09:21:39+00:00 ad524d46f36bbc32033bb72ba42958f12bf49b06 When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can potentially have the same number of physical address bits as the 64-bit host ("Enhanced Legacy PAE Paging"). This means, in theory, we could have up to 52 bits of physical address in a pte. The 32-bit kernel uses a 32-bit unsigned long to represent a pfn. This means that it can only represent physical addresses up to 32+12=44 bits wide. Rather than widening pfns everywhere, just set 2^44 as the Linux x86_32-PAE architectural limit for physical address size. This is a bugfix for two cases: 1. running a 32-bit PAE kernel on a machine with more than 64GB RAM. 2. running a 32-bit PAE Xen guest on a host machine with more than 64GB RAM In both cases, a pte could need to have more than 36 bits of physical, and masking it to 36-bits will cause fairly severe havoc. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Cc: Jan Beulich <jbeulich@novell.com> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> 
When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can
potentially have the same number of physical address bits as the
64-bit host ("Enhanced Legacy PAE Paging").  This means, in theory,
we could have up to 52 bits of physical address in a pte.

The 32-bit kernel uses a 32-bit unsigned long to represent a pfn.
This means that it can only represent physical addresses up to 32+12=44
bits wide.  Rather than widening pfns everywhere, just set 2^44 as the
Linux x86_32-PAE architectural limit for physical address size.

This is a bugfix for two cases:
1. running a 32-bit PAE kernel on a machine with
  more than 64GB RAM.
2. running a 32-bit PAE Xen guest on a host machine with
  more than 64GB RAM

In both cases, a pte could need to have more than 36 bits of physical,
and masking it to 36-bits will cause fairly severe havoc.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jan Beulich <jbeulich@novell.com>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86: fix broken math-emu with lazy allocation of fpu area 2008-06-04T11:11:46+00:00 Suresh Siddha suresh.b.siddha@intel.com 2008-05-23T23:26:37+00:00 e8a496ac8cd00cabbdaa373db4818a9ad19a1c5a Fix the math emulation that got broken with the recent lazy allocation of FPU area. init_fpu() need to be added for the math-emulation path aswell for the FPU area allocation. math emulation enabled kernel booted fine with this, in the presence of "no387 nofxsr" boot param. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: hpa@zytor.com Cc: mingo@elte.hu Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
Fix the math emulation that got broken with the recent lazy allocation of FPU
area. init_fpu() need to be added for the math-emulation path aswell
for the FPU area allocation.

math emulation enabled kernel booted fine with this, in the presence
of "no387 nofxsr" boot param.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: hpa@zytor.com
Cc: mingo@elte.hu
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
x86: prevent PGE flush from interruption/preemption 2008-05-23T16:16:15+00:00 Ingo Molnar mingo@elte.hu 2008-05-12T19:21:15+00:00 b1979a5fda7869a790f4fd83fb06c78498d26ba1 CR4 manipulation is not protected against interrupts and preemption, but KVM uses smp_function_call to manipulate the X86_CR4_VMXE bit either from the CPU hotplug code or from the kvm_init call. We need to protect the CR4 manipulation from both interrupts and preemption. Original bug report: http://lkml.org/lkml/2008/5/7/48 Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=10642 This is not a regression from 2.6.25, it's a long standing and hard to trigger bug. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 
CR4 manipulation is not protected against interrupts and preemption,
but KVM uses smp_function_call to manipulate the X86_CR4_VMXE bit
either from the CPU hotplug code or from the kvm_init call.

We need to protect the CR4 manipulation from both interrupts and
preemption.

Original bug report: http://lkml.org/lkml/2008/5/7/48
Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=10642

This is not a regression from 2.6.25, it's a long standing and hard to
trigger bug.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
x86: strengthen 64-bit p?d_bad() 2008-05-20T15:14:45+00:00 Hugh Dickins hugh@veritas.com 2008-05-20T12:59:47+00:00 a8375bd81cf99cb81be37127eaf08316ecb87619 The x86_64 pgd_bad(), pud_bad(), pmd_bad() inlines have differed from their x86_32 counterparts in a couple of ways: they've been unnecessarily weak (e.g. letting 0 or 1 count as good), and were typed as unsigned long. Strengthen them and return int. The PAE pmd_bad was too weak before, allowing any junk in the upper half; but got strengthened by the patch correcting its ~PAGE_MASK to ~PTE_MASK. The PAE pud_bad already said ~PTE_MASK; and since it folds into pgd_bad, and we don't set the protection bits at that level, it'll do as is. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
The x86_64 pgd_bad(), pud_bad(), pmd_bad() inlines have differed from
their x86_32 counterparts in a couple of ways: they've been unnecessarily
weak (e.g. letting 0 or 1 count as good), and were typed as unsigned long.
Strengthen them and return int.

The PAE pmd_bad was too weak before, allowing any junk in the upper half;
but got strengthened by the patch correcting its ~PAGE_MASK to ~PTE_MASK.
The PAE pud_bad already said ~PTE_MASK; and since it folds into pgd_bad,
and we don't set the protection bits at that level, it'll do as is.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
xen: use PTE_MASK in pte_mfn() 2008-05-20T14:51:21+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-05-20T07:26:24+00:00 cbb3077cbe718795d7ae5d78ed11659ca73c97b9 Use PTE_MASK to extract mfn from pte. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Tested-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Use PTE_MASK to extract mfn from pte.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86: use PTE_MASK rather than ad-hoc mask 2008-05-20T14:51:21+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-05-20T07:26:23+00:00 ba23cef5c23cf1e9298032037d919157553d1211 Use ~PTE_MASK to extract the non-pfn parts of the pte (ie, the pte flags), rather than constructing an ad-hoc mask. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Tested-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Use ~PTE_MASK to extract the non-pfn parts of the pte (ie, the pte
flags), rather than constructing an ad-hoc mask.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86: clarify use of _PAGE_CHG_MASK 2008-05-20T14:51:21+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-05-20T07:26:22+00:00 86aaf4fd4ea25ddde05772d03b93dbce23c0ead1 _PAGE_CHG_MASK is defined as the set of bits not updated by pte_modify(); specifically, the pfn itself, and the Accessed and Dirty bits (which are updated by hardware). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Tested-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
_PAGE_CHG_MASK is defined as the set of bits not updated by
pte_modify(); specifically, the pfn itself, and the Accessed and Dirty
bits (which are updated by hardware).

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86: use PTE_MASK in pgtable_32.h 2008-05-20T14:51:21+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-05-20T07:26:21+00:00 7f84133af6aaa86e9ef0e9e1970655439a8cf3a1 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86: use PTE_MASK in 32-bit PAE 2008-05-20T14:51:21+00:00 Jeremy Fitzhardinge jeremy@goop.org 2008-05-20T07:26:20+00:00 a4d6886270a5c892d71cd6e09186196a150a50dc Use PTE_MASK in 3-level pagetables (ie, 32-bit PAE). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Tested-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Use PTE_MASK in 3-level pagetables (ie, 32-bit PAE).

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>