linux-toradex.git/arch, branch v2.6.29.2

x86, PAT: Remove page granularity tracking for vm_insert_pfn maps

2009-04-27T17:37:04+00:00

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 
Tested-by: Arkadiusz Miskiewicz 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Suresh Siddha 
Cc: Jesse Barnes 
LKML-Reference: <20090408223716.GC3493@linux-os.sc.intel.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Chris Wright

KVM: is_long_mode() should check for EFER.LMA

2009-04-27T17:37:04+00:00

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 
Signed-off-by: Avi Kivity 
Signed-off-by: Chris Wright

KVM: VMX: Update necessary state when guest enters long mode

2009-04-27T17:37:04+00:00

upstream commit: 401d10dee083bda281f2fdcdf654080313ba30ec

setup_msrs() should be called when entering long mode to save the
shadow state for the 64-bit guest state.

Using vmx_set_efer() in enter_lmode() removes some duplicated code
and also ensures we call setup_msrs(). We can safely pass the value
of shadow_efer to vmx_set_efer() as no other bits in the efer change
while enabling long mode (guest first sets EFER.LME, then sets CR0.PG
which causes a vmexit where we activate long mode).

With this fix, is_long_mode() can check for EFER.LMA set instead of
EFER.LME and 5e23049e86dd298b72e206b420513dbc3a240cd9 can be reverted.

Signed-off-by: Amit Shah 
Signed-off-by: Avi Kivity 
Signed-off-by: Chris Wright

KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked

2009-04-27T17:37:03+00:00

upstream commit: 4780c65904f0fc4e312ee2da9383eacbe04e61ea

While the PIT is masked the guest cannot ack the irq, so the reinject logic
will never allow the interrupt to be injected.

Fix by resetting the reinjection counters on unmask.

Unbreaks Xen.

Signed-off-by: Avi Kivity 
Signed-off-by: Chris Wright

KVM: Add CONFIG_HAVE_KVM_IRQCHIP

2009-04-27T17:37:03+00:00

upstream commit: 5d9b8e30f543a9f21a968a4cda71e8f6d1c66a61

Two KVM archs support irqchips and two don't.  Add a Kconfig item to
make selecting between the two models easier.

Signed-off-by: Avi Kivity 
Signed-off-by: Chris Wright

KVM: Fix missing smp tlb flush in invlpg

2009-04-27T17:37:03+00:00

upstream commit: 4539b35881ae9664b0e2953438dd83f5ee02c0b4

When kvm emulates an invlpg instruction, it can drop a shadow pte, but
leaves the guest tlbs intact.  This can cause memory corruption when
swapping out.

Without this the other cpu can still write to a freed host physical page.
tlb smp flush must happen if rmap_remove is called always before mmu_lock
is released because the VM will take the mmu_lock before it can finally add
the page to the freelist after swapout. mmu notifier makes it safe to flush
the tlb after freeing the page (otherwise it would never be safe) so we can do
a single flush for multiple sptes invalidated.

Cc: stable@kernel.org
Signed-off-by: Andrea Arcangeli 
Acked-by: Marcelo Tosatti 
Signed-off-by: Avi Kivity 
[mtosatti: backport to 2.6.29]
Signed-off-by: Chris Wright

x86: disable X86_PTRACE_BTS for now

2009-04-27T17:37:02+00:00

upstream commit: d45b41ae8da0f54aec0eebcc6f893ba5f22a1e8e

Oleg Nesterov found a couple of races in the ptrace-bts code
and fixes are queued up for it but they did not get ready in time
for the merge window. We'll merge them in v2.6.31 - until then
mark the feature as CONFIG_BROKEN. There's no user-space yet
making use of this so it's not a big issue.

Cc: 
Signed-off-by: Ingo Molnar 
[chrisw: trivial 2.6.29 backport]
Signed-off-by: Chris Wright

powerpc: Fix data-corrupting bug in __futex_atomic_op

2009-04-27T17:37:01+00:00

upstream commit: 306a82881b14d950d59e0b59a55093a07d82aa9a

Richard Henderson pointed out that the powerpc __futex_atomic_op has a
bug: it will write the wrong value if the stwcx. fails and it has to
retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
by the result from the first time around the loop.  This happens
because it uses the same register for 'oparg' (an input) as it uses
for the result.

This fixes it by using separate registers for 'oparg' and 'ret'.

Cc: stable@kernel.org
Signed-off-by: Paul Mackerras 
Signed-off-by: Chris Wright

x86: fix broken irq migration logic while cleaning up multiple vectors

2009-04-27T17:37:00+00:00

upstream commit: 68a8ca593fac82e336a792226272455901fa83df

Impact: fix spurious IRQs

During irq migration, we send a low priority interrupt to the previous
irq destination. This happens in non interrupt-remapping case after interrupt
starts arriving at new destination and in interrupt-remapping case after
modifying and flushing the interrupt-remapping table entry caches.

This low priority irq cleanup handler can cleanup multiple vectors, as
multiple irq's can be migrated at almost the same time. While
there will be multiple invocations of irq cleanup handler (one cleanup
IPI for each irq migration), first invocation of the cleanup handler
can potentially cleanup more than one vector (as the first invocation can
see the requests for more than vector cleanup). When we cleanup multiple
vectors during the first invocation of the smp_irq_move_cleanup_interrupt(),
other vectors that are to be cleanedup can still be pending in the local
cpu's IRR (as smp_irq_move_cleanup_interrupt() runs with interrupts disabled).

When we are ready to unhook a vector corresponding to an irq, check if that
vector is registered in the local cpu's IRR. If so skip that cleanup and
do a self IPI with the cleanup vector, so that we give a chance to
service the pending vector interrupt and then cleanup that vector
allocation once we execute the lowest priority handler.

This fixes spurious interrupts seen when migrating multiple vectors
at the same time.

[ This is apparently possible even on conventional xapic, although to
  the best of our knowledge it has never been seen.  The stable
  maintainers may wish to consider this one for -stable. ]

[suresh: backport to 2.6.29]
Signed-off-by: Suresh Siddha 
Cc: Eric W. Biederman 
Signed-off-by: H. Peter Anvin 
Cc: stable@kernel.org
Signed-off-by: Chris Wright

sparc64: Fix bug in ("sparc64: Flush TLB before releasing pages.")

2009-04-27T17:36:58+00:00

[ No upstream commit, this regression was added only to 2.6.29.1 ]

Unfortunately I merged an earlier version of commit
b6816b706138c3870f03115071872cad824f90b4 ("sparc64: Flush TLB before
releasing pages.") than what I actually tested and merged upstream.

Simply diffing asm/tlb_64.h in Linus's tree vs. what ended up in
2.6.29.1 confirms this.

Sync things up to fix BUG() triggers some users are seeing.

Reported-by: Dennis Gilmore 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright