linux-toradex.git/arch, branch v2.6.29.4 Linux kernel for Apalis and Colibri modules KVM: Make EFER reads safe when EFER does not exist 2009-05-18T23:35:19+00:00 Avi Kivity avi@redhat.com 2009-05-03T15:50:55+00:00 21616cb7a37a63b9f33ea2e45ab6d29910b43fd2 commit e286e86e6d2042d67d09244aa0e05ffef75c9d54 upstream. Some processors don't have EFER; don't oops if userspace wants us to read EFER when we check NX. Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e286e86e6d2042d67d09244aa0e05ffef75c9d54 upstream.

Some processors don't have EFER; don't oops if userspace wants us to
read EFER when we check NX.

Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
KVM: SVM: Remove port 80 passthrough 2009-05-18T23:35:18+00:00 Avi Kivity avi@redhat.com 2009-05-11T11:21:10+00:00 a6ddabcdf09bf394de04ca5c772129cb8fc6e179 commit 99f85a28a78e96d28907fe036e1671a218fee597 upstream. KVM optimizes guest port 80 accesses by passthing them through to the host. Some AMD machines die on port 80 writes, allowing the guest to hard-lock the host. Remove the port passthrough to avoid the problem. Reported-by: Piotr Jaroszyński <p.jaroszynski@gmail.com> Tested-by: Piotr Jaroszyński <p.jaroszynski@gmail.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 99f85a28a78e96d28907fe036e1671a218fee597 upstream.

KVM optimizes guest port 80 accesses by passthing them through to the host.
Some AMD machines die on port 80 writes, allowing the guest to hard-lock the
host.

Remove the port passthrough to avoid the problem.

Reported-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Tested-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
tracing: x86, mmiotrace: fix range test 2009-05-08T22:45:12+00:00 Stuart Bennett stuart@freedesktop.org 2009-04-28T19:17:48+00:00 0bdcc4d3d0ad03cdcabbc689415e2e6924cd8636 commit 33015c85995716d03f6293346cf05a1908b0fb9a upstream. Matching on (addr == (p->addr + p->len)) causes problems when mappings are adjacent. [ Impact: fix mmiotrace confusion on adjacent iomaps ] Signed-off-by: Stuart Bennett <stuart@freedesktop.org> Acked-by: Pekka Paalanen <pq@iki.fi> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 33015c85995716d03f6293346cf05a1908b0fb9a upstream.

Matching on (addr == (p->addr + p->len)) causes problems when mappings
are adjacent.

[ Impact: fix mmiotrace confusion on adjacent iomaps ]

Signed-off-by: Stuart Bennett <stuart@freedesktop.org>
Acked-by: Pekka Paalanen <pq@iki.fi>
Cc: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1240946271-7083-2-git-send-email-stuart@freedesktop.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc: Sanitize stack pointer in signal handling code 2009-05-08T22:45:05+00:00 Josh Boyer jwboyer@linux.vnet.ibm.com 2009-04-28T15:15:59+00:00 669e1834c4c57a880260a0e720266b1077d7d355 This has been backported to 2.6.29.x from commit efbda86098 in Linus' tree On powerpc64 machines running 32-bit userspace, we can get garbage bits in the stack pointer passed into the kernel. Most places handle this correctly, but the signal handling code uses the passed value directly for allocating signal stack frames. This fixes the issue by introducing a get_clean_sp function that returns a sanitized stack pointer. For 32-bit tasks on a 64-bit kernel, the stack pointer is masked correctly. In all other cases, the stack pointer is simply returned. Additionally, we pass an 'is_32' parameter to get_sigframe now in order to get the properly sanitized stack. The callers are know to be 32 or 64-bit statically. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This has been backported to 2.6.29.x from commit efbda86098 in Linus' tree

On powerpc64 machines running 32-bit userspace, we can get garbage bits in the
stack pointer passed into the kernel.  Most places handle this correctly, but
the signal handling code uses the passed value directly for allocating signal
stack frames.

This fixes the issue by introducing a get_clean_sp function that returns a
sanitized stack pointer.  For 32-bit tasks on a 64-bit kernel, the stack
pointer is masked correctly.  In all other cases, the stack pointer is simply
returned.

Additionally, we pass an 'is_32' parameter to get_sigframe now in order to
get the properly sanitized stack.  The callers are know to be 32 or 64-bit
statically.

Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case 2009-05-08T22:45:03+00:00 Yinghai Lu yinghai@kernel.org 2009-04-18T08:43:46+00:00 3b442bfc78d351343fa539c63afde75d7b134316 commit 044cd80942e47b9de0915b627902adf05c52377f upstream. e820_all_mapped need end is (addr + size) instead of (addr + size - 1) Cc: stable@kernel.org Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 044cd80942e47b9de0915b627902adf05c52377f upstream.

e820_all_mapped need end is (addr + size) instead of (addr + size - 1)

Cc: stable@kernel.org
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
x86-64: fix FPU corruption with signals and preemption 2009-05-08T22:45:03+00:00 Suresh Siddha suresh.b.siddha@intel.com 2009-04-09T22:24:34+00:00 40434618e61a539f1acb24c8adb166470a361f3d commit 06c38d5e36b12d040839ff224e805146c0368556 upstream. In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 06c38d5e36b12d040839ff224e805146c0368556 upstream.

In 64bit signal delivery path, clear_used_math() was happening before saving
the current active FPU state on to the user stack for signal handling. Between
clear_used_math() and the state store on to the user stack, potentially we
can get a page fault for the user address and can block. Infact, while testing
we were hitting the might_fault() in __clear_user() which can do a schedule().

At a later point in time, we will schedule back into this process and
resume the save state (using "xsave/fxsave" instruction) which can lead
to DNA fault. And as used_math was cleared before, we will reinit the FP state
in the DNA fault and continue. This reinit will result in loosing the
FPU state of the process.

Move clear_used_math() to a point after the FPU state has been stored
onto the user stack.

This issue is present from a long time (even before the xsave changes
and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x
series because of the __clear_user() in this path, which has an explicit
__cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY.

[ Impact: fix FPU state corruption ]

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
KVM: x86: release time_page on vcpu destruction 2009-05-08T22:44:59+00:00 Joerg Roedel joerg.roedel@amd.com 2009-04-24T16:05:07+00:00 b2cc4458c8e2d07b998ebcaf6380d6f7d64aa0e7 upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb Not releasing the time_page causes a leak of that page or the compound page it is situated in. Cc: stable@kernel.org Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 7f1ea208968f021943d4103ba59e06bb6d8239cb

Not releasing the time_page causes a leak of that page or the compound
page it is situated in.

Cc: stable@kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
KVM: MMU: disable global page optimization 2009-05-08T22:44:59+00:00 Marcelo Tosatti mtosatti@redhat.com 2009-04-24T21:18:27+00:00 d595990048ad17ba7b0ad50438ed64f88b7c25ca upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1 Complexity to fix it not worthwhile the gains, as discussed in http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649. Cc: stable@kernel.org Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com> [mtosatti: backport to 2.6.29] Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: bf47a760f66add7870fba33ab50f58b550d6bbd1

Complexity to fix it not worthwhile the gains, as discussed
in http://article.gmane.org/gmane.comp.emulators.kvm.devel/28649.
    
Cc: stable@kernel.org
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
[mtosatti: backport to 2.6.29]
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
x86, PAT: Remove page granularity tracking for vm_insert_pfn maps 2009-04-27T17:37:04+00:00 Pallipadi, Venkatesh venkatesh.pallipadi@intel.com 2009-04-18T09:08:04+00:00 bc7bc5df2deb79df8f3686c81e2e5f43710efb18 upstream commit: 4b065046273afa01ec8e3de7da407e8d3599251d This change resolves the problem of too many single page entries in pat_memtype_list and "freeing invalid memtype" errors with i915, reported here: http://marc.info/?l=linux-kernel&m=123845244713183&w=2 Remove page level granularity track and untrack of vm_insert_pfn. memtype tracking at page granularity does not scale and cleaner approach would be for the driver to request a type for a bigger IO address range or PCI io memory range for that device, either at mmap time or driver init time and just use that type during vm_insert_pfn. This patch just removes the track/untrack of vm_insert_pfn. That means we will be in same state as 2.6.28, with respect to these APIs. Newer APIs for the drivers to request a memtype for a bigger region is coming soon. [ Impact: fix Xorg startup warnings and hangs ] Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Tested-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 4b065046273afa01ec8e3de7da407e8d3599251d

This change resolves the problem of too many single page entries
in pat_memtype_list and "freeing invalid memtype" errors with i915,
reported here:

  http://marc.info/?l=linux-kernel&m=123845244713183&w=2

Remove page level granularity track and untrack of vm_insert_pfn.
memtype tracking at page granularity does not scale and cleaner
approach would be for the driver to request a type for a bigger
IO address range or PCI io memory range for that device, either at
mmap time or driver init time and just use that type during
vm_insert_pfn.

This patch just removes the track/untrack of vm_insert_pfn. That
means we will be in same state as 2.6.28, with respect to these APIs.

Newer APIs for the drivers to request a memtype for a bigger region
is coming soon.

[ Impact: fix Xorg startup warnings and hangs ]

Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Tested-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
KVM: is_long_mode() should check for EFER.LMA 2009-04-27T17:37:04+00:00 Amit Shah amit.shah@qumranet.com 2009-04-17T22:40:13+00:00 e8c4851a2ad9c7ada702141e621f127cb203c41e upstream commit: 41d6af119206e98764b4ae6d264d63acefcf851e is_long_mode currently checks the LongModeEnable bit in EFER instead of the LongModeActive bit. This is wrong, but we survived this till now since it wasn't triggered. This breaks guests that go from long mode to compatibility mode. This is noticed on a solaris guest and fixes bug #1842160 Signed-off-by: Amit Shah <amit.shah@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
upstream commit: 41d6af119206e98764b4ae6d264d63acefcf851e

is_long_mode currently checks the LongModeEnable bit in
EFER instead of the LongModeActive bit. This is wrong, but
we survived this till now since it wasn't triggered. This
breaks guests that go from long mode to compatibility mode.

This is noticed on a solaris guest and fixes bug #1842160

Signed-off-by: Amit Shah <amit.shah@qumranet.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>