kernel.git/arch/x86/include, branch linux-2.6.30.y

KVM: VMX: Check cpl before emulating debug register access

2009-10-05T15:27:52Z

(cherry picked from commit 0a79b009525b160081d75cef5dbf45817956acf2) Debug registers may only be accessed from cpl 0. Unfortunately, vmx will code to emulate the instruction even though it was issued from guest userspace, possibly leading to an unexpected trap later. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman

x86/i386: Make sure stack-protector segment base is cache aligned

2009-09-24T15:27:21Z

commit 1ea0d14e480c245683927eecc03a70faf06e80c8 upstream. The Intel Optimization Reference Guide says: In Intel Atom microarchitecture, the address generation unit assumes that the segment base will be 0 by default. Non-zero segment base will cause load and store operations to experience a delay. - If the segment base isn't aligned to a cache line boundary, the max throughput of memory operations is reduced to one [e]very 9 cycles. [...] Assembly/Compiler Coding Rule 15. (H impact, ML generality) For Intel Atom processors, use segments with base set to 0 whenever possible; avoid non-zero segment base address that is not aligned to cache line boundary at all cost. We can't avoid having a non-zero base for the stack-protector segment, but we can make it cache-aligned. Signed-off-by: Jeremy Fitzhardinge LKML-Reference: <4AA01893.6000507@goop.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

KVM: MMU: Use different shadows when EFER.NXE changes

2009-09-09T03:33:31Z

(cherry picked from commit 9645bb56b31a1b70ab9e470387b5264cafc04aa9) A pte that is shadowed when the guest EFER.NXE=1 is not valid when EFER.NXE=0; if bit 63 is set, the pte should cause a fault, and since the shadow EFER always has NX enabled, this won't happen. Fix by using a different shadow page table for different EFER.NXE bits. This allows vcpus to run correctly with different values of EFER.NXE, and for transitions on this bit to be handled correctly without requiring a full flush. Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: Deal with interrupt shadow state for emulated instructions

2009-09-09T03:33:31Z

(cherry picked from commit 310b5d306c1aee7ebe32f702c0e33e7988d50646) We currently unblock shadow interrupt state when we skip an instruction, but failing to do so when we actually emulate one. This blocks interrupts in key instruction blocks, in particular sti; hlt; sequences If the instruction emulated is an sti, we have to block shadow interrupts. The same goes for mov ss. pop ss also needs it, but we don't currently emulate it. Without this patch, I cannot boot gpxe option roms at vmx machines. This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469 Signed-off-by: Glauber Costa CC: H. Peter Anvin CC: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

KVM: Introduce {set/get}_interrupt_shadow()

2009-09-09T03:33:30Z

This patch introduces set/get_interrupt_shadow(), that does exactly what the name suggests. It also replaces open code that explicitly does it with the now existent functions. It differs slightly from upstream, because upstream merged it after gleb's interrupt rework, that we don't ship. Just for reference, upstream changelog is (2809f5d2c4cfad171167b131bb2a21ab65eba40f): This patch replaces drop_interrupt_shadow with the more general set_interrupt_shadow, that can either drop or raise it, depending on its parameter. It also adds ->get_interrupt_shadow() for future use. Signed-off-by: Glauber Costa Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman

x86: fix assembly constraints in native_save_fl()

2009-08-16T21:18:43Z

commit f1f029c7bfbf4ee1918b90a431ab823bed812504 upstream. From Gabe Black in bugzilla 13888: native_save_fl is implemented as follows: 11static inline unsigned long native_save_fl(void) 12{ 13 unsigned long flags; 14 15 asm volatile("# __raw_save_flags\n\t" 16 "pushf ; pop %0" 17 : "=g" (flags) 18 : /* no input */ 19 : "memory"); 20 21 return flags; 22} If gcc chooses to put flags on the stack, for instance because this is inlined into a larger function with more register pressure, the offset of the flags variable from the stack pointer will change when the pushf is performed. gcc doesn't attempt to understand that fact, and address used for pop will still be the same. It will write to somewhere near flags on the stack but not actually into it and overwrite some other value. I saw this happen in the ide_device_add_all function when running in a simulator I work on. I'm assuming that some quirk of how the simulated hardware is set up caused the code path this is on to be executed when it normally wouldn't. A simple fix might be to change "=g" to "=r". Reported-by: Gabe Black Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86: Fix movq immediate operand constraints in uaccess.h

2009-07-30T21:40:03Z

commit ebe119cd0929df4878f758ebf880cb435e4dcaaf upstream. The movq instruction, generated by __put_user_asm() when used for 64-bit data, takes a sign-extended immediate ("e") not a zero-extended immediate ("Z"). Signed-off-by: H. Peter Anvin Cc: Uros Bizjak Signed-off-by: Greg Kroah-Hartman

x86: Fix movq immediate operand constraints in uaccess_64.h

2009-07-30T21:40:01Z

commit 155b73529583c38f30fd394d692b15a893960782 upstream. arch/x86/include/asm/uaccess_64.h uses wrong asm operand constraint ("ir") for movq insn. Since movq sign-extends its immediate operand, "er" constraint should be used instead. Attached patch changes all uses of __put_user_asm in uaccess_64.h to use "er" when "q" insn suffix is involved. Patch was compile tested on x86_64 with defconfig. Signed-off-by: Uros Bizjak Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86/pci: insert ioapic resource before assigning unassigned resources

2009-07-30T21:39:55Z

commit 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82 upstream. Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?) Dann bisected it down to: commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029 Date: Tue Feb 19 03:21:20 2008 -0800 x86: multi pci root bus with different io resource range, on 64-bit It turns out that: 1. that AMD-based systems have two HT chains. 2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc 3. that multi-peer-root patch will try to split root resources to peer root resources according to PCI conf of NB 4. PCI core assigns unassigned resources, but they overlap with BARs that are used by ioapic addr of io4 and 8132. The reason: at that point ioapic address are not inserted yet. Solution is to insert ioapic resources into the tree a bit earlier. Reported-by: Stephen Frost Reported-and-Tested-by: dann frazier Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

x86: Fix fixmap page order for FIX_TEXT_POKE0,1

2009-07-30T21:39:42Z

commit 12b9d7ccb841805e347fec8f733f368f43ddba40 upstream. Masami reported: > Since the fixmap pages are assigned higher address to lower, > text_poke() has to use it with inverted order (FIX_TEXT_POKE1 > to FIX_TEXT_POKE0). I prefer to just invert the order of the fixmap declaration. It's simpler and more straightforward. Backward fixmaps seems to be used by both x86 32 and 64. It's really rare but a nasty bug, because it only hurts when instructions to patch are crossing a page boundary. If this happens, the fixmap write accesses will spill on the following fixmap, which may very well crash the system. And this does not crash the system, it could leave illegal instructions in place. Thanks Masami for finding this. It seems to have crept into the 2.6.30-rc series, so this calls for a -stable inclusion. Signed-off-by: Mathieu Desnoyers Acked-by: Masami Hiramatsu LKML-Reference: <20090701213722.GH19926@Krystal> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman