summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2008-09-08KVM: MMU: Fix torn shadow pteAvi Kivity
(cherry picked from commit cd5998ebfbc9e6cb44408efa217c15d7eea13675) The shadow code assigns a pte directly in one place, which is nonatomic on i386 can can cause random memory references. Fix by using an atomic setter. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08x86: work around MTRR mask setting, v2Ingo Molnar
commit 9754a5b840a209bc1f192d59f63e81b698a55ac8 upstream x86: work around MTRR mask setting, v2 improve the debug printout: - make it actually display something - print it only once would be nice to have a WARN_ONCE() facility, to feed such things to kerneloops.org. Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08sparc64: Fix cmdline_memory_size handling bugs.David S. Miller
[ Upstream commit f2b6079464fc73cf12f08248180a618f05033a70 ] First, lmb_enforce_memory_limit() interprets it's argument (mostly, heh) as a size limit not an address limit. So pass the raw cmdline_memory_size value into it. And we don't need to check it against zero, lmb_enforce_memory_limit() does that for us. Next, free_initmem() needs special handling when the kernel command line trims the available memory. The problem case is if the trimmed out memory is where the kernel image itself resides. When that memory is trimmed out, we don't add those physical ram areas to the sparsemem active ranges, amongst other things. Which means that this free_initmem() code will free up invalid page structs, resulting in either crashes or hangs. Just quick fix this by not freeing initmem at all if "mem=" was given on the boot command line. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08sparc64: Fix overshoot in nid_range().David S. Miller
[ Upstream commit c918dcce92f76bb9903e4d049f4780bad384c207 ] If 'start' does not begin on a page boundary, we can overshoot past 'end'. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"Samuel Sieb
commit c6744955d0ec0cb485c28c51eeb7185e260f6172 upstream Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped booting starting at v2.6.22. The reason is this commit: > commit f25f64ed5bd3c2932493681bdfdb483ea707da0a > Author: Juergen Beisert <juergen@kreuzholzen.de> > Date: Sun Jul 22 11:12:38 2007 +0200 > > x86: Replace NSC/Cyrix specific chipset access macros by inlined functions. this commit activated a macro which was dormant before due to (buggy) macro side-effects. I've looked through various datasheets and found that the GXm and GXLV Geode processors don't have an incrementor. Remove the incrementor setup entirely. As the incrementor value differs according to clock speed and we would hope that the BIOS configures it correctly, it is probably the right solution. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-09-08x86: work around MTRR mask settingYinghai Lu
commit 38cc1c3df77c1bb739a4766788eb9fa49f16ffdf upstream Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is usable. Booting with mtrr_show showed us the BIOS-initialized MTRR settings - which are all wrong. So the root cause is that the BIOS has not set the mask correctly: > [ 0.429971] MSR00000200: 00000000d0000000 > [ 0.433305] MSR00000201: 0000000ff0000800 > should be ==> [ 0.433305] MSR00000201: 0000003ff0000800 > > [ 0.436638] MSR00000202: 00000000e0000000 > [ 0.439971] MSR00000203: 0000000fe0000800 > should be ==> [ 0.439971] MSR00000203: 0000003fe0000800 > > [ 0.443304] MSR00000204: 0000000000000006 > [ 0.446637] MSR00000205: 0000000c00000800 > should be ==> [ 0.446637] MSR00000205: 0000003c00000800 > > [ 0.449970] MSR00000206: 0000000400000006 > [ 0.453303] MSR00000207: 0000000fe0000800 > should be ==> [ 0.453303] MSR00000207: 0000003fe0000800 > > [ 0.456636] MSR00000208: 0000000420000006 > [ 0.459970] MSR00000209: 0000000ff0000800 > should be ==> [ 0.459970] MSR00000209: 0000003ff0000800 So detect this borkage and add the prefix 111. Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20x86: fix setup code crashes on my old 486 boxJoerg Roedel
commit 7b27718bdb1b70166383dec91391df5534d449ee upstream yesterday I tried to reactivate my old 486 box and wanted to install a current Linux with latest kernel on it. But it turned out that the latest kernel does not boot because the machine crashes early in the setup code. After some debugging it turned out that the problem is the query_ist() function. If this interrupt with that function is called the machine simply locks up. It looks like a BIOS bug. Looking for a workaround for this problem I wrote the attached patch. It checks for the CPUID instruction and if it is not implemented it does not call the speedstep BIOS function. As far as I know speedstep should be available since some Pentium earliest. Alan Cox observed that it's available since the Pentium II, so cpuid levels 4 and 5 can be excluded altogether. H. Peter Anvin cleaned up the code some more: > Right in concept, but I dislike the implementation (duplication of the > CPU detect code we already have). Could you try this patch and see if > it works for you? which, with a small modification to fix a build error with it the resulting kernel boots on my machine. Signed-off-by: Joerg Roedel <joro@8bytes.org> Signed-off-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Handle stack trace attempts before irqstacks are setup.David S. Miller
[ Upstream commit 6f63e781eaf6a741fc65f773017154b20ed4ce3b ] Things like lockdep can try to do stack backtraces before the irqstack blocks have been setup. So don't try to match their ranges so early on. Also, remove unused variable in save_stack_trace(). Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Implement IRQ stacks.David S. Miller
[ Upstream commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd ] Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Make global reg dumping even more useful.David S. Miller
[ Upstream commit 5afe27380bc42454254c9c83c045240249c15e35 ] Record one more level of stack frame program counter. Particularly when lockdep and all sorts of spinlock debugging is enabled, figuring out the caller of spin_lock() is difficult when the cpu is stuck on the lock. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Fix recursion in stack overflow detection handling.David S. Miller
[ Upstream commit c7498081a6f5d96c9f3243b6b5e020352903bfd2 ] The calls down into prom_printf() when we detect an overflowed stack can recurse again since the overflow stack will be "below" the current kernel stack limit. Prevent this by just returning straight if we are on the stack overflow safe stack already. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Fix end-of-stack checking in save_stack_trace().David S. Miller
[ Upstream commit 433c5f706856689be25928a99636e724fb3ea7cf ] Bug reported by Alexander Beregalov. Before we dereference the stack frame or try to peek at the pt_regs magic value, make sure the entire object is within the kernel stack bounds. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20x86: amd opteron TOM2 mask val fixYinghai Lu
commit 8004dd965b13b01a96def054d420f6df7ff22d53 upstream. there is a typo in the mask value, need to remove that extra 0, to avoid 4bit clearing. Signed-off-by: Yinghal Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: maximilian attems <max@stro.at> Cc: Peter Palfrader <weasel@debian.org> Cc: dann frazier <dannf@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20KVM: ia64: Fix irq disabling leak in error handling codeJulia Lawall
(cherry picked from commit cab7a1eeeb007be309cd99cf14407261a72d2418) There is a call to local_irq_restore in the normal exit case, so it would seem that there should be one on an error return as well. The semantic patch that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; expression E,E1,E2; @@ local_irq_save(l); ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E,l) when any when strict ( if (...) { ... when != local_irq_restore(l) when != spin_unlock_irqrestore(E1,l) + local_irq_restore(l); return ...; } | if (...) + {local_irq_restore(l); return ...; + } | spin_unlock_irqrestore(E2,l); | local_irq_restore(l); ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20KVM: task switch: translate guest segment limit to virt-extension byte ↵Marcelo Tosatti
granular field (cherry picked from commit c93cd3a58845012df2d658fecd0ac99f7008d753) If 'g' is one then limit is 4kb granular. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20KVM: Avoid instruction emulation when event delivery is pendingAvi Kivity
(cherry-picked from commit 577bdc496614ced56d999bbb425e85adf2386490) When an event (such as an interrupt) is injected, and the stack is shadowed (and therefore write protected), the guest will exit. The current code will see that the stack is shadowed and emulate a few instructions, each time postponing the injection. Eventually the injection may succeed, but at that time the guest may be unwilling to accept the interrupt (for example, the TPR may have changed). This occurs every once in a while during a Windows 2008 boot. Fix by unshadowing the fault address if the fault was due to an event injection. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20KVM: task switch: use seg regs provided by subarch instead of reading from GDTMarcelo Tosatti
(cherry-picked from commit 34198bf8426276a2ce1e97056a0f02d43637e5ae) There is no guarantee that the old TSS descriptor in the GDT contains the proper base address. This is the case for Windows installation's reboot-via-triplefault. Use guest registers instead. Also translate the address properly. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20KVM: task switch: segment base is linear addressMarcelo Tosatti
(cherry picked from commit 98899aa0e0bf5de05850082be0eb837058c09ea5) The segment base is always a linear address, so translate before accessing guest memory. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Do not clobber %g7 in setcontext() trap.David S. Miller
[ Upstream commit 0a4949c4414af2eb91414bcd8e2a8ac3706f7dde ] That's the userland thread register, so we should never try to change it like this. Based upon glibc bug nptl/6577 and suggestions by Jakub Jelinek. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-20sparc64: Fix global reg snapshotting on self-cpu.David S. Miller
[ Upstream commit 17b6f586b8e27914b36c9ed7f3e4d289e6274a80 ] We were picking %i7 out of the wrong register window stack slot. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Add compat handler for PTRACE_GETSIGINFOAndreas Schwab
commit e4cc58944c1e2ce41e3079d4eb60c95e7ce04b2b upstream Current versions of gdb require a working implementation of PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo contains pointers it must be converted when passed to a 32-bit debugger. Signed-off-by: Andreas Schwab <schwab@suse.de> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06Kprobe smoke test lockdep warningPeter Zijlstra
[ Upstream commit d54191b85e294c46f05a2249b1f55ae54930bcc7 ] On Mon, 2008-04-21 at 18:54 -0400, Masami Hiramatsu wrote: > Thank you for reporting. > > Actually, kprobes tries to fixup thread's flags in post_kprobe_handler > (which is called from kprobe_exceptions_notify) by > trace_hardirqs_fixup_flags(pt_regs->flags). However, even the irq flag > is set in pt_regs->flags, true hardirq is still off until returning > from do_debug. Thus, lockdep assumes that hardirq is off without annotation. > > IMHO, one possible solution is that fixing hardirq flags right after > notify_die in do_debug instead of in post_kprobe_handler. My reply to BZ 10489: > [ 2.707509] Kprobe smoke test started > [ 2.709300] ------------[ cut here ]------------ > [ 2.709420] WARNING: at kernel/lockdep.c:2658 check_flags+0x4d/0x12c() > [ 2.709541] Modules linked in: > [ 2.709588] Pid: 1, comm: swapper Not tainted 2.6.25.jml.057 #1 > [ 2.709588] [<c0126acc>] warn_on_slowpath+0x41/0x51 > [ 2.709588] [<c010bafc>] ? save_stack_trace+0x1d/0x3b > [ 2.709588] [<c0140a83>] ? save_trace+0x37/0x89 > [ 2.709588] [<c011987d>] ? kernel_map_pages+0x103/0x11c > [ 2.709588] [<c0109803>] ? native_sched_clock+0xca/0xea > [ 2.709588] [<c0142958>] ? mark_held_locks+0x41/0x5c > [ 2.709588] [<c0382580>] ? kprobe_exceptions_notify+0x322/0x3af > [ 2.709588] [<c0142aff>] ? trace_hardirqs_on+0xf1/0x119 > [ 2.709588] [<c03825b3>] ? kprobe_exceptions_notify+0x355/0x3af > [ 2.709588] [<c0140823>] check_flags+0x4d/0x12c > [ 2.709588] [<c0143c9d>] lock_release+0x58/0x195 > [ 2.709588] [<c038347c>] ? __atomic_notifier_call_chain+0x0/0x80 > [ 2.709588] [<c03834d6>] __atomic_notifier_call_chain+0x5a/0x80 > [ 2.709588] [<c0383508>] atomic_notifier_call_chain+0xc/0xe > [ 2.709588] [<c013b6d4>] notify_die+0x2d/0x2f > [ 2.709588] [<c038168a>] do_debug+0x67/0xfe > [ 2.709588] [<c0381287>] debug_stack_correct+0x27/0x30 > [ 2.709588] [<c01564c0>] ? kprobe_target+0x1/0x34 > [ 2.709588] [<c0156572>] ? init_test_probes+0x50/0x186 > [ 2.709588] [<c04fae48>] init_kprobes+0x85/0x8c > [ 2.709588] [<c04e947b>] kernel_init+0x13d/0x298 > [ 2.709588] [<c04e933e>] ? kernel_init+0x0/0x298 > [ 2.709588] [<c04e933e>] ? kernel_init+0x0/0x298 > [ 2.709588] [<c0105ef7>] kernel_thread_helper+0x7/0x10 > [ 2.709588] ======================= > [ 2.709588] ---[ end trace 778e504de7e3b1e3 ]--- > [ 2.709588] possible reason: unannotated irqs-off. > [ 2.709588] irq event stamp: 370065 > [ 2.709588] hardirqs last enabled at (370065): [<c0382580>] kprobe_exceptions_notify+0x322/0x3af > [ 2.709588] hardirqs last disabled at (370064): [<c0381bb7>] do_int3+0x1d/0x7d > [ 2.709588] softirqs last enabled at (370050): [<c012b464>] __do_softirq+0xfa/0x100 > [ 2.709588] softirqs last disabled at (370045): [<c0107438>] do_softirq+0x74/0xd9 > [ 2.714751] Kprobe smoke test passed successfully how I love this stuff... Ok, do_debug() is a trap, this can happen at any time regardless of the machine's IRQ state. So the first thing we do is fix up the IRQ state. Then we call this die notifier stuff; and return with messed up IRQ state... YAY. So, kprobes fudges it.. notify_die(DIE_DEBUG) kprobe_exceptions_notify() post_kprobe_handler() modify regs->flags trace_hardirqs_fixup_flags(regs->flags); <--- must be it So what's the use of modifying flags if they're not meant to take effect at some point. /me tries to reproduce issue; enable kprobes test thingy && boot OK, that reproduces.. So the below makes it work - but I'm not getting this code; at the time I wrote that stuff I CC'ed each and every kprobe maintainer listed in the usual places but got no reposonse - can some please explain this stuff to me? Are the saved flags only for the TF bit or are they made in full effect later (and if so, where) ? Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06x86: io delay - add checking for NULL early paramCyrill Gorcunov
[ Upstream commit d6cd7effcc5e0047faf15ab0a54c980f1a616a07 ] Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: akpm@linux-foundation.org Cc: andi@firstfloor.org Signed-off-by: Ingo Molnar <mingo@elte.hu> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-06x86: idle process - add checking for NULL early paramCyrill Gorcunov
[ Upstream commit ab6bc3e343fbe3be4a0f67225e849d0db6b4b7ac ] Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: akpm@linux-foundation.org Cc: andi@firstfloor.org Signed-off-by: Ingo Molnar <mingo@elte.hu> CC: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called alreadyThomas Renninger
commit a1531acd43310a7e4571d52e8846640667f4c74b upstream Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec749a3519069d9390561b5636a75c7579) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: Thomas Renninger <trenn@suse.de> Cc: Andi Kleen <andi@firstfloor.org> Cc: Len Brown <lenb@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01UML - Fix boot crashJeff Dike
commit 7c1fed03b9fa32d4323d5caa6a9c7dcdd7eba767 upstream My copying of linux/init.h didn't go far enough. The definition of __used singled out gcc minor version 3, but didn't care what the major version was. This broke when unit-at-a-time was added and gcc started throwing out initcalls. This results in an early boot crash when ptrace tries to initialize a process with an empty, uninitialized register set. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01x86: fix kernel_physical_mapping_init() for large x86 systemsIngo Molnar
based on e22146e610bb7aed63282148740ab1d1b91e1d90 upstream Fix bug in kernel_physical_mapping_init() that causes kernel page table to be built incorrectly for systems with greater than 512GB of memory. Signed-off-by: Jack Steiner <steiner@sgi.com> Cc: linux-mm@kvack.org Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Oliver Pinter <oliver.pntr@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01sparc64: Fix cpufreq notifier registry.David S. Miller
[ Upstream commit 7ae93f51d7fa8b9130d47e0b7d17979a165c5bc3 ] Based upon a report by Daniel Smolik. We do it too early, which triggers a BUG in cpufreq_register_notifier(). Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01sparc64: Fix lockdep issues in LDC protocol layer.David S. Miller
[ Upstream commit b7c2a75725dee9b5643a0aae3a4cb47f52e00a49 ] We're calling request_irq() with a IRQs disabled. No straightforward fix exists because we want to enable these IRQs and setup state atomically before getting into the IRQ handler the first time. What happens now is that we mark the VIRQ to not be automatically enabled by request_irq(). Then we make explicit enable_irq() calls when we grab the LDC channel. This way we don't need to call request_irq() illegally under the LDC channel lock any more. Bump LDC version and release date. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01x86: fix crash due to missing debugctlmsr on AMD K6-3Jan Kratochvil
commit d536b1f86591fb081c7a56eab04e711eb4dab951 upstream currently if you use PTRACE_SINGLEBLOCK on AMD K6-3 (i586) it will crash. Kernel now wrongly assumes existing DEBUGCTLMSR MSR register there. Removed the assumption also for some other non-K6 CPUs but I am not sure there (but it can only bring small inefficiency there if my assumption is wrong). Based on info from Roland McGrath, Chuck Ebbert and Mikulas Patocka. More info at: https://bugzilla.redhat.com/show_bug.cgi?id=456175 Signed-off-by: Jan Kratochvil <jan.kratochvil@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01x86, suspend, acpi: enter Big Real ModeH. Peter Anvin
Commit 3bf2e77453a87c22eb57ed4926760ac131c84459 upstream x86, suspend, acpi: enter Big Real Mode The explanation for recent video BIOS suspend quirk failures is that the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff) instead of ordinary Real Mode (*.limit = 0xffff). This patch changes the segment descriptors to Big Real Mode instead. The segment descriptor registers (what Intel calls "segment cache") is always active. The only thing that changes based on CR0.PE is how it is *loaded* and the interpretation of the CS flags. The segment descriptor registers contain of the following sub-registers: selector (the "visible" part), base, limit and flags. In protected mode or long mode, they are loaded from descriptors (or fs.base or gs.base can be manipulated directly in long mode.) In real mode, the only thing changed by a segment register load is the selector and the base, where the base <- selector << 4. In particular, *the limit and the flags are not changed*. As far as the handling of the CS flags: a code segment cannot be writable in protected mode, whereas it is "just another segment" in real mode, so there is some kind of quirk that kicks in for this when CR0.PE <- 0. I'm not sure if this is accomplished by actually changing the cs.flags register or just changing the interpretation; it might be something that is CPU-specific. In particular, the Transmeta CPUs had an explicit "CS is writable if you're in real mode" override, so even if you had loaded CS with an execute-only segment it'd be writable (but not readable!) on return to real mode. I'm not at all sure if that is how other CPUs behave. Signed-off-by: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-01x86 reboot quirks: add Dell Precision WorkStation T5400Ingo Molnar
commit fab3b58d3b242b5903f78d60d86803a8aecdf6de upstream as reported in: "reboot=bios is mandatory on Dell T5400 server." http://bugzilla.kernel.org/show_bug.cgi?id=11108 add a DMI reboot quirk. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01Patch Upstream: x86 ptrace: fix PTRACE_GETFPXREGS errorRoland McGrath
commit 45fdc3a7624a4a48185a04ae0abab5f9793d8952 upstream ptrace has always returned only -EIO for all failures to access registers. The user_regset calls are allowed to return a more meaningful variety of errors. The REGSET_XFP calls use -ENODEV for !cpu_has_fxsr hardware. Make ptrace return the traditional -EIO instead of the error code from the user_regset call. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: MMU: Fix potential race setting upper shadow ptes on nonpae hostsAvi Kivity
Original-Commit-Hash: c23a6fe17abf8562e675465f8d55ba1a551d314d The direct mapped shadow code (used for real mode and two dimensional paging) sets upper-level ptes using direct assignment rather than calling set_shadow_pte(). A nonpae host will split this into two writes, which opens up a race if another vcpu accesses the same memory area. Fix by calling set_shadow_pte() instead of assigning directly. Noticed by Izik Eidus. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: MMU: nuke shadowed pgtable pages and ptes on memslot destructionMarcelo Tosatti
Original-Commit-Hash: 3cc312f03e06a8fa39ecb4cc0189efc2bd888899 Flush the shadow mmu before removing regions to avoid stale entries. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: x86 emulator: Fix HLT instructionMohammed Gamal
Original-Commit-Hash: bcc542267538e9ba933d08b4cd4ebd796e03a3d7 This patch fixes issue encountered with HLT instruction under FreeDOS's HIMEM XMS Driver. The HLT instruction jumped directly to the done label and skips updating the EIP value, therefore causing the guest to spin endlessly on the same instruction. The patch changes the instruction so that it writes back the updated EIP value. Signed-off-by: Mohammed Gamal <m.gamal005@gmail.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: VMX: Add ept_sync_context in flush_tlbSheng Yang
Original-Commit-Hash: 73f785350b92e1a3af945340f7d10f3978193cba Fix a potention issue caused by kvm_mmu_slot_remove_write_access(). The old behavior don't sync EPT TLB with modified EPT entry, which result in inconsistent content of EPT TLB and EPT table. Signed-off-by: Sheng Yang <sheng.yang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: mmu_shrink: kvm_mmu_zap_page requires slots_lock to be heldMarcelo Tosatti
Original-Commit-Hash: 64f6a0c041bd8fc100a0d655058bdbc31feda03c kvm_mmu_zap_page() needs slots lock held (rmap_remove->gfn_to_memslot, for example). Since kvm_lock spinlock is held in mmu_shrink(), do a non-blocking down_read_trylock(). Untested. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: SVM: fix suspend/resume supportJoerg Roedel
Original-Commit-Hash: ab6267b708bec563891294488f2e854be404bdaf On suspend the svm_hardware_disable function is called which frees all svm_data variables. On resume they are not re-allocated. This patch removes the deallocation of svm_data from the hardware_disable function to the hardware_unsetup function which is not called on suspend. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-08-01KVM: VMX: Fix a wrong usage of vmcs_configSheng Yang
Original-Commit-Hash: 406046a9638a455876b030853862e576a4378d29 The function ept_update_paging_mode_cr0() write to CPU_BASED_VM_EXEC_CONTROL based on vmcs_config.cpu_based_exec_ctrl. That's wrong because the variable may not consistent with the content in the CPU_BASE_VM_EXEC_CONTROL MSR. Signed-off-by: Sheng Yang <sheng.yang@intel.com> Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-10Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: fix /dev/mem compatibility under PAT
2008-07-10arch/x86/kernel/.gitignore: Added vmlinux.lds to .gitignore file because it ↵Daniel Guilak
shouldn't be tracked. Signed-off-by: Daniel Guilak <daniel@danielguilak.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-10x86: fix /dev/mem compatibility under PATVenkatesh Pallipadi
Add ioremap_default(), which gives a sane mapping without worrying about type conflicts. Use it in /dev/mem read in place of ioremap(), as with ioremap(), any mapping of the region (other than UC_MINUS) will cause a conflict and failure of /dev/mem read. Should address the vbetest failure reported at: http://bugzilla.kernel.org/show_bug.cgi?id=11057 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-08powerpc: Add missing reference to coherent_dma_maskVitaly Bordug
There is dma_mask in of_device upon of_platform_device_create() but we don't actually set coherent_dma_mask. This may cause weird behavior of USB subsystem using of_device USB host drivers. Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-08[MIPS] Fix 32bit kernels on R4k with 128 byte cache line sizeThomas Bogendoerfer
The generated copy_page for R4k CPU with a 128 byte cache line size used Create Dirty Exclusive cache line operations even if only part of the cache line was filled. This change avoids generating cache operations, if only part of the cache line size is copied in one loop. It also increases the maxmimum loop size, because the generated code even fits into the available space for r4k CPUs with 128 byte cache line size. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-07-08[MIPS] Atlas, decstation: Fix section mismatches triggered by defconfigsShane McDonald
Resolve these mismatches by defining affected functions with the __cpuinit attribute, rather than __init. Signed-off-by: Shane McDonald <mcdonald.shane@gmail.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-07-07Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: Revert "PCI: Correct last two HP entries in the bfsort whitelist"
2008-07-07Revert "PCI: Correct last two HP entries in the bfsort whitelist"Jesse Barnes
This reverts commit a1676072558854b95336c8f7db76b0504e909a0a. It duplicates the change from 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a and only one should be applied, otherwise some of the Dell quirks are lost. Thanks to Tony Camuso for catching this. Acked-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-07-07[UML] fix gcc ICEs and unresolved externsJeff Dike
There are various constraints on the use of unit-at-a-time: - i386 uses no-unit-at-a-time for pre-4.0 (not 4.3) - x86_64 uses unit-at-a-time always Uli reported a crash on x86_64 with gcc 4.1.2 with unit-at-a-time, resulting in commit c0a18111e571138747a98af18b3a2124df56a0d1 Ingo reported a gcc internal error with gcc 4.3 with no-unit-at-a-timem, resulting in 22eecde2f9034764a3fd095eecfa3adfb8ec9a98 Benny Halevy is seeing extern inlines not resolved with gcc 4.3 with no-unit-at-a-time This patch reintroduces unit-at-a-time for gcc >= 4.0, bringing back the possibility of Uli's crash. If that happens, we'll debug it. I started seeing both the internal compiler errors and unresolved inlines on Fedora 9. This patch fixes both problems, without so far reintroducing the crash reported by Uli. Signed-off-by: Jeff Dike <jdike@linux.intel.com> Cc: Benny Halevy <bhalevy@panasas.com> Cc: Adrian Bunk <bunk@kernel.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-07powerpc: Fix unterminated of_device_id array in legacy_serial.cBenjamin Herrenschmidt
A recent patch to legacy_serial.c factored out some code by using the of_match_node() facility to match a node against an array of possible matches. However, the patch didn't properly terminate the array causing potential crashes in cases where no match is found. In addition, the name of the array was poorly chosen for a static symbol making debugging harder. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-01 11:31:09 +0000