aboutsummaryrefslogtreecommitdiff
path: root/arch/x86
AgeCommit message (Collapse)Author
2008-03-12documentation: Move power-related files to Documentation/power/Randy Dunlap
Move 00-INDEX entries to power/00-INDEX (and add entry for pm_qos_interface.txt). Update references to moved filenames. Fix some trailing whitespace. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-03-11x86: remove quicklistsThomas Gleixner
quicklists cause a serious memory leak on 32-bit x86, as documented at: http://bugzilla.kernel.org/show_bug.cgi?id=9991 the reason is that the quicklist pool is a special-purpose cache that grows out of proportion. It is not accounted for anywhere and users have no way to even realize that it's the quicklists that are causing RAM usage spikes. It was supposed to be a relatively small pool, but as demonstrated by KOSAKI Motohiro, they can grow as large as: Quicklists: 1194304 kB given how much trouble this code has caused historically, and given that Andrew objected to its introduction on x86 (years ago), the best option at this point is to remove them. [ any performance benefits of caching constructed pgds should be implemented in a more generic way (possibly within the page allocator), while still allowing constructed pages to be allocated by other workloads. ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-11x86: ia32 syscall restart fixRoland McGrath
The code to restart syscalls after signals depends on checking for a negative orig_ax, and for particular negative -ERESTART* values in ax. These fields are 64 bits and for a 32-bit task they get zero-extended. The syscall restart behavior is lost, a regression from a native 32-bit kernel and from 64-bit tasks' behavior. This patch fixes the problem by doing sign-extension where it matters. For orig_ax, the only time the value should be -1 but winds up as 0x0ffffffff is via a 32-bit ptrace call. So the patch changes ptrace to sign-extend the 32-bit orig_eax value when it's stored; it doesn't change the checks on orig_ax, though it uses the new current_syscall() inline to better document the subtle importance of the used of signedness there. The ax value is stored a lot of ways and it seems hard to get them all sign-extended at their origins. So for that, we use the current_syscall_ret() to sign-extend it only for 32-bit tasks at the time of the -ERESTART* comparisons. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-11x86: ioremap, remove WARN_ON()Ingo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-10fix BIOS PCI config cycle buglet causing ACPI boot regressionIngo Molnar
I figured out another ACPI related regression today. randconfig testing triggered an early boot-time hang on a laptop of mine (32-bit x86, config attached) - the screen was scrolling ACPI AML exceptions [with no serial port and no early debugging available]. v2.6.24 works fine on that laptop with the same .config, so after a few hours of bisection (had to restart it 3 times - other regressions interacted), it honed in on this commit: | 10270d4838bdc493781f5a1cf2e90e9c34c9142f is first bad commit | | Author: Linus Torvalds <torvalds@woody.linux-foundation.org> | Date: Wed Feb 13 09:56:14 2008 -0800 | | acpi: fix acpi_os_read_pci_configuration() misuse of raw_pci_read() reverting this commit ontop of -rc5 gave a correctly booting kernel. But this commit fixes a real bug so the real question is, why did it break the bootup? After quite some head-scratching, the following change stood out: - pci_id->bus = tu8; + pci_id->bus = val; pci_id->bus is defined as u16: struct acpi_pci_id { u16 segment; u16 bus; ... and 'tu8' changed from u8 to u32. So previously we'd unconditionally mask the return value of acpi_os_read_pci_configuration() (raw_pci_read()) to 8 bits, but now we just trust whatever comes back from the PCI access routines and only crop it to 16 bits. But if the high 8 bits of that result contains any noise then we'll write that into ACPI's PCI ID descriptor and confuse the heck out of the rest of ACPI. So lets check the PCI-BIOS code on that theory. We have this codepath for 8-bit accesses (arch/x86/pci/pcbios.c:pci_bios_read()): switch (len) { case 1: __asm__("lcall *(%%esi); cld\n\t" "jc 1f\n\t" "xor %%ah, %%ah\n" "1:" : "=c" (*value), "=a" (result) : "1" (PCIBIOS_READ_CONFIG_BYTE), "b" (bx), "D" ((long)reg), "S" (&pci_indirect)); Aha! The "=a" output constraint puts the full 32 bits of EAX into *value. But if the BIOS's routines set any of the high bits to nonzero, we'll return a value with more set in it than intended. The other, more common PCI access methods (v1 and v2 PCI reads) clear out the high bits already, for example pci_conf1_read() does: switch (len) { case 1: *value = inb(0xCFC + (reg & 3)); which explicitly converts the return byte up to 32 bits and zero-extends it. So zero-extending the result in the PCI-BIOS read routine fixes the regression on my laptop. ( It might fix some other long-standing issues we had with PCI-BIOS during the past decade ... ) Both 8-bit and 16-bit accesses were buggy. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-11lguest: Revert 1ce70c4fac3c3954bd48c035f448793867592bc0, fix real problem.Rusty Russell
Ahmed managed to crash the Host in release_pgd(), which cannot be a Guest bug, and indeed it wasn't. The bug was that handing a 0 as the address of the toplevel page table being manipulated can cause the lookup code in find_pgdir() to return an uninitialized cache entry (we shadow up to 4 top level page tables for each Guest). Commit 37cc8d7f963ba2deec29c9b68716944516a3244f introduced this behaviour in the Guest, uncovering the bug. The patch which he submitted (which removed the /4 from the index calculation) simply ensured that these high-indexed entries hit the early exit path of guest_set_pmd(). But you get lots of segfaults in guest userspace as the PMDs aren't being updated. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2008-03-11lguest: Sanitize the lguest clock.Rusty Russell
Now the TSC code handles a zero return from calculate_cpu_khz(), lguest can simply pass through the value it gets from the Host: if non-zero, all the normal TSC code applies. Otherwise (or if the Host really doesn't support TSC), the clocksource code will fall back to the slower but reasonable lguest clock. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2008-03-07x86_64: make ptrace always sign-extend orig_ax to 64 bitsRoland McGrath
This makes 64-bit ptrace calls setting the 64-bit orig_ax field for a 32-bit task sign-extend the low 32 bits up to 64. This matches what a 64-bit debugger expects when tracing a 32-bit task. This follows on my "x86_64 ia32 syscall restart fix". This didn't matter until that was fixed. The debugger ignores or zeros the high half of every register slot it sets (including the orig_rax pseudo-register) uniformly. It expects that the setting of the low 32 bits always has the same meaning as a 32-bit debugger setting those same 32 bits with native 32-bit facilities. This never arose before because the syscall restart check never matched any -ERESTART* values due to lack of sign extension. Before that fix, even 32-bit ptrace setting orig_eax to -1 failed to trigger the restart check anyway. So this was never noticed as a regression of 64-bit debuggers vs 32-bit debuggers on the same 64-bit kernel. Signed-off-by: Roland McGrath <roland@redhat.com> [ Changed to just do the sign-extension unconditionally on x86-64, since orig_ax is always just a small integer and doesn't need the full 64-bit range ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-07x86-boot: don't request VBE2 informationPeter Korsgaard
The new x86 setup code (4fd06960f120) broke booting on an old P3/500MHz with an onboard Voodoo3 of mine. After debugging it, it turned out to be caused by the fact that the vesa probing now asks for VBE2 data. Disassembing the video BIOS shows that it overflows the vesa_general_info structure when VBE2 data is requested because the source addresses for the information strings which get strcpy'ed to the buffer lie outside the 32K BIOS code (and hence contain long sequences of 0xff's). E.G.: get_vbe_controller_info: 00002A9C 60 pushaw 00002A9D 1E push ds 00002A9E 0E push cs 00002A9F 1F pop ds 00002AA0 2BC9 sub cx,cx 00002AA2 6626813D56424532 cmp dword [es:di],0x32454256 ; "VBE2" 00002AAA 7501 jnz .1 00002AAC 41 inc cx .1: 00002AAD 51 push cx 00002AAE B91400 mov cx,0x14 00002AB1 BED47F mov si, controller_header 00002AB4 57 push di 00002AB5 F3A4 rep movsb ; copy vbe1.2 header 00002AB7 B9EC00 mov cx,0xec 00002ABA 2AC0 sub al,al 00002ABC F3AA rep stosb ; zero pad remainder 00002ABE 5F pop di 00002ABF E8EB0D call word get_memory 00002AC2 C1E002 shl ax,0x2 00002AC5 26894512 mov [es:di+0x12],ax ; total memory 00002AC9 26C745040003 mov word [es:di+0x4],0x300 ; VBE version 00002ACF 268C4D08 mov [es:di+0x8],cs 00002AD3 268C4D10 mov [es:di+0x10],cs 00002AD7 59 pop cx 00002AD8 E361 jcxz .done ; VBE2 requested? 00002ADA 8D9D0001 lea bx,[di+0x100] 00002ADE 53 push bx 00002ADF 87DF xchg bx,di ; di now points to 2nd half 00002AE1 26C747140001 mov word [es:bx+0x14],0x100 ; sw rev 00002AE7 26897F06 mov [es:bx+0x6],di ; oem string 00002AEB 268C4708 mov [es:bx+0x8],es 00002AEF BE5280 mov si,0x8052 ; oem string 00002AF2 E87A1B call word strcpy 00002AF5 26897F0E mov [es:bx+0xe],di ; video mode list 00002AF9 268C4710 mov [es:bx+0x10],es 00002AFD B91E00 mov cx,0x1e 00002B00 BEE87F mov si,vidmodes 00002B03 F3A5 rep movsw 00002B05 26897F16 mov [es:bx+0x16],di ; oem vendor 00002B09 268C4718 mov [es:bx+0x18],es 00002B0D BE2480 mov si,0x8024 ; oem vendor 00002B10 E85C1B call word strcpy 00002B13 26897F1A mov [es:bx+0x1a],di ; oem product 00002B17 268C471C mov [es:bx+0x1c],es 00002B1B BE3880 mov si,0x8038 ; oem product 00002B1E E84E1B call word strcpy 00002B21 26897F1E mov [es:bx+0x1e],di ; oem product rev 00002B25 268C4720 mov [es:bx+0x20],es 00002B29 BE4580 mov si,0x8045 ; oem product rev 00002B2C E8401B call word strcpy 00002B2F 58 pop ax 00002B30 B90001 mov cx,0x100 00002B33 2BCF sub cx,di 00002B35 03C8 add cx,ax 00002B37 2AC0 sub al,al 00002B39 F3AA rep stosb ; zero pad .done: 00002B3B 1F pop ds 00002B3C 61 popaw 00002B3D B84F00 mov ax,0x4f 00002B40 C3 ret (The full BIOS can be found at http://peter.korsgaard.com/vgabios.bin if interested). The old setup code didn't ask for VBE2 info, and the new code doesn't actually do anything with the extra information, so the fix is to simply not request it. Other BIOS'es might have the same problem. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-07x86: re-add reboot fixupsIngo Molnar
Jan Beulich noticed that the reboot fixups went missing during reboot.c unification. (commit 4d022e35fd7e07c522c7863fee6f07e53cf3fc14) Geode and a few other rare boards with special reboot quirks are affected. Reported-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-07x86: fix typo in step.cJan Beulich
TIF_DEBUGCTLMSR has no meaning in the actual MSR... Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-07x86: fix merge mistake in i387.cJan Beulich
convert_fxsr_to_user() in 2.6.24's i387_32.c did this, and convert_to_fxsr() also does the inverse, so I assume it's an oversight that it is no longer being done. [ mingo@elte.hu: we encode it this way because there's no space for the 'FPU Last Instruction Opcode' (->fop) field in the legacy user_i387_ia32_struct that PTRACE_GETFPREGS/PTRACE_SETFPREGS uses. it's probably pure legacy - i'd be surprised if any user-space relied on the FPU Last Opcode in any way. But indeed we used to do it previously so the most conservative thing is to preserve that piece of information. ] Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-07x86: clear DF before calling signal handlerAurelien Jarno
The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. Linux had this behavior/bug forever, but this becomes a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: H. Peter Anvin <hpa@zytor.com>
2008-03-05[CPUFREQ] Remove debugging message from e_powersaverDave Jones
We don't need to printk a message every time we transition. Leave the code there, but ifdef'd out, as it's useful when adding support for new processors. Reported-by: Petr Titěra <P.Titera@century.cz> Signed-off-by: Dave Jones <davej@redhat.com>
2008-03-04Kprobes: indicate kretprobe support in KconfigAnanth N Mavinakayanahalli
Add CONFIG_HAVE_KRETPROBES to the arch/<arch>/Kconfig file for relevant architectures with kprobes support. This facilitates easy handling of in-kernel modules (like samples/kprobes/kretprobe_example.c) that depend on kretprobes being present in the kernel. Thanks to Sam Ravnborg for helping make the patch more lean. Per Mathieu's suggestion, added CONFIG_KRETPROBES and fixed up dependencies. Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Acked-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04x86: a P4 is a P6 not an i486Hugh Dickins
P4 has been coming out as CPU_FAMILY=4 instead of 6: fix MPENTIUM4 typo. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86/xen: fix DomU boot problem x86: not set node to cpu_to_node if the node is not online x86, i387: fix ptrace leakage using init_fpu()
2008-03-04Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm: x86: disable KVM for Voyager and friends KVM: VMX: Avoid rearranging switched guest msrs while they are loaded KVM: MMU: Fix race when instantiating a shadow pte KVM: Route irq 0 to vcpu 0 exclusively KVM: Avoid infinite-frequency local apic timer KVM: make MMU_DEBUG compile again KVM: move alloc_apic_access_page() outside of non-preemptable region KVM: SVM: fix Windows XP 64 bit installation crash KVM: remove the usage of the mmap_sem for the protection of the memory slots. KVM: emulate access to MSR_IA32_MCG_CTL KVM: Make the supported cpuid list a host property rather than a vm property KVM: Fix kvm_arch_vcpu_ioctl_set_sregs so that set_cr0 works properly KVM: SVM: set NM intercept when enabling CR0.TS in the guest KVM: SVM: Fix lazy FPU switching
2008-03-04x86/xen: fix DomU boot problemIan Campbell
Construct Xen guest e820 map with a hole between 640K-1M. It's pure luck that Xen kernels have gotten away with it in the past. The patch below seems like the right thing to do. It certainly boots in a domU without the DMI problem (without any of the other related patches such as Alexander's). Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Tested-by: Mark McLoughlin <markmc@redhat.com> Acked-by: Mark McLoughlin <markmc@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-04x86: not set node to cpu_to_node if the node is not onlineYinghai Lu
resolve boot problem reported by Mel Gorman: http://lkml.org/lkml/2008/2/13/404 init_cpu_to_node will use cpu->apic (from MADT or mptable) and apic->node(from SRAT or AMD config space with k8_bus_64.c) to have cpu->node mapping, and later identify_cpu will overwrite them again...(with nearby_node...) this patch checks if the node is online, otherwise it will not update cpu_node map. so keep cpu_node map to online node before identify_cpu..., to prevent possible error. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-04x86, i387: fix ptrace leakage using init_fpu()Suresh Siddha
This bug got introduced by the recent i387 merge: commit 4421011120b2304e5c248ae4165a2704588aedf1 Author: Roland McGrath <roland@redhat.com> Date: Wed Jan 30 13:31:50 2008 +0100 x86: x86 i387 user_regset Current usage of unlazy_fpu() in ptrace specific routines is wrong. unlazy_fpu() will not init fpu if the task never used math. So the ptrace calls can expose the parent tasks FPU data in some cases. Replace it with the init_fpu() which will init the math state, if the task never used math before. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Acked-by: Thomas Gleixner <tglx@linutronix.de>
2008-03-04x86: disable KVM for Voyager and friendsRandy Dunlap
Most classic Pentiums don't have hardware virtualization extension, and building kvm with Voyager, Visual Workstation, or NUMAQ generates spurious failures. Signed-off-by: Avi Kivity <avi@qumranet.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
2008-03-04KVM: VMX: Avoid rearranging switched guest msrs while they are loadedAvi Kivity
KVM tries to run as much as possible with the guest msrs loaded instead of host msrs, since switching msrs is very expensive. It also tries to minimize the number of msrs switched according to the guest mode; for example, MSR_LSTAR is needed only by long mode guests. This optimization is done by setup_msrs(). However, we must not change which msrs are switched while we are running with guest msr state: - switch to guest msr state - call setup_msrs(), removing some msrs from the list - switch to host msr state, leaving a few guest msrs loaded An easy way to trigger this is to kexec an x86_64 linux guest. Early during setup, the guest will switch EFER to not include SCE. KVM will stop saving MSR_LSTAR, and on the next msr switch it will leave the guest LSTAR loaded. The next host syscall will end up in a random location in the kernel. Fix by reloading the host msrs before changing the msr list. Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: MMU: Fix race when instantiating a shadow pteAvi Kivity
For improved concurrency, the guest walk is performed concurrently with other vcpus. This means that we need to revalidate the guest ptes once we have write-protected the guest page tables, at which point they can no longer be modified. The current code attempts to avoid this check if the shadow page table is not new, on the assumption that if it has existed before, the guest could not have modified the pte without the shadow lock. However the assumption is incorrect, as the racing vcpu could have modified the pte, then instantiated the shadow page, before our vcpu regains control: vcpu0 vcpu1 fault walk pte modify pte fault in same pagetable instantiate shadow page lookup shadow page conclude it is old instantiate spte based on stale guest pte We could do something clever with generation counters, but a test run by Marcelo suggests this is unnecessary and we can just do the revalidation unconditionally. The pte will be in the processor cache and the check can be quite fast. Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: Avoid infinite-frequency local apic timerAvi Kivity
If the local apic initial count is zero, don't start a an hrtimer with infinite frequency, locking up the host. Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: make MMU_DEBUG compile againMarcelo Tosatti
the cr3 variable is now inside the vcpu->arch structure. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: move alloc_apic_access_page() outside of non-preemptable regionMarcelo Tosatti
alloc_apic_access_page() can sleep, while vmx_vcpu_setup is called inside a non preemptable region. Move it after put_cpu(). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: SVM: fix Windows XP 64 bit installation crashJoerg Roedel
While installing Windows XP 64 bit wants to access the DEBUGCTL and the last branch record (LBR) MSRs. Don't allowing this in KVM causes the installation to crash. This patch allow the access to these MSRs and fixes the issue. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Markus Rechberger <markus.rechberger@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-04KVM: remove the usage of the mmap_sem for the protection of the memory slots.Izik Eidus
This patch replaces the mmap_sem lock for the memory slots with a new kvm private lock, it is needed beacuse untill now there were cases where kvm accesses user memory while holding the mmap semaphore. Signed-off-by: Izik Eidus <izike@qumranet.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-03x86: revert "x86: CPA: avoid split of alias mappings"Rafael J. Wysocki
Revert: commit 8be8f54bae3453588011cad06363813a5293af53 Author: Thomas Gleixner <tglx@linutronix.de> Date: Sat Feb 23 20:43:21 2008 +0100 x86: CPA: avoid split of alias mappings because it clearly mishandles the case when __change_page_attr(), called from __change_page_attr_set_clr(), changes cpa->processed to 1 and cpa_process_alias(cpa) is executed right after that. This crashes my x86-64 test box early in the boot process (ref. http://bugzilla.kernel.org/show_bug.cgi?id=10140#c4). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-03-03KVM: emulate access to MSR_IA32_MCG_CTLJoerg Roedel
Injecting an GP when accessing this MSR lets Windows crash when running some stress test tools in KVM. So this patch emulates access to this MSR. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Markus Rechberger <markus.rechberger@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-03KVM: Make the supported cpuid list a host property rather than a vm propertyAvi Kivity
One of the use cases for the supported cpuid list is to create a "greatest common denominator" of cpu capabilities in a server farm. As such, it is useful to be able to get the list without creating a virtual machine first. Since the code does not depend on the vm in any way, all that is needed is to move it to the device ioctl handler. The capability identifier is also changed so that binaries made against -rc1 will fail gracefully. Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-03KVM: Fix kvm_arch_vcpu_ioctl_set_sregs so that set_cr0 works properlyPaul Knowles
Whilst working on getting a VM to initialize in to IA32e mode I found this issue. set_cr0 relies on comparing the old cr0 to the new one to work correctly. Move the assignment below so the compare can work. Signed-off-by: Paul Knowles <paul@transitive.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-03KVM: SVM: set NM intercept when enabling CR0.TS in the guestJoerg Roedel
Explicitly enable the NM intercept in svm_set_cr0 if we enable TS in the guest copy of CR0 for lazy FPU switching. This fixes guest SMP with Linux under SVM. Without that patch Linux deadlocks or panics right after trying to boot the other CPUs. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Markus Rechberger <markus.rechberger@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-03-03KVM: SVM: Fix lazy FPU switchingJoerg Roedel
If the guest writes to cr0 and leaves the TS flag at 0 while vcpu->fpu_active is also 0, the TS flag in the guest's cr0 gets lost. This leads to corrupt FPU state an causes Windows Vista 64bit to crash very soon after boot. This patch fixes this bug. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Markus Rechberger <markus.rechberger@amd.com> Signed-off-by: Avi Kivity <avi@qumranet.com>
2008-02-29xen: mask out SEP from CPUIDJeremy Fitzhardinge
Fix 32-on-64 pvops kernel: we don't want userspace using syscall/sysenter, even if the hypervisor supports it, so mask it out from CPUID. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: disable BTS ptrace extensions for nowIngo Molnar
revert the BTS ptrace extension for now. based on general objections from Roland McGrath: http://lkml.org/lkml/2008/2/21/323 we'll let the BTS functionality cook some more and re-enable it in v2.6.26. We'll leave the dead code around to help the development of this code. (X86_BTS is not defined at the moment) Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: CPA: avoid split of alias mappingsThomas Gleixner
avoid over-eager large page splitup. When the target area needs to be split or is split already (ioremap) then the current code enforces the split of large mappings in the alias regions even if we could avoid it. Use a separate variable processed in the cpa_data structure to carry the number of pages which have been processed instead of reusing the numpages variable. This keeps numpages intact and gives the alias code a chance to keep large mappings intact. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: delay the export removal of init_mmIngo Molnar
delay the removal of this symbol export by one more kernel release, giving external modules such as VirtualBox a chance to stop using it. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: fix leak un ioremap_page_range() failureIngo Molnar
Jan Beulich noticed it during code review that if a driver's ioremap() fails (say due to -ENOMEM) then we might leak the struct vm_area. Free it properly. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86 vdso: fix build locale dependencyRoland McGrath
Priit Laes discovered that the sed command processing nm output was sensitive to locale settings. This was addressed in commit 03994f01e8b72b3d01fd3d09d1cc7c9f421a727c by using [:alnum:] in place of [a-zA-Z0-9]. But that solution too is locale-dependent and may not always match the identifiers it needs to. The better fix is just to run sed et al with a fixed locale setting in all builds. Signed-off-by: Roland McGrath <roland@redhat.com> CC: Priit Laes <plaes@plaes.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: restore vsyscall64 prochandlerThomas Gleixner
a recent fix: commit ce28b9864b853803320c3f1d8de1b81aa4120b14 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Feb 20 23:57:30 2008 +0100 x86: fix vsyscall wreckage removed the broken /kernel/vsyscall64 handler completely. This triggers the following debug check: sysctl table check failed: /kernel/vsyscall64 No proc_handler Restore the sane part of the proc handler. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-29x86: tls prevent_tail_callRoland McGrath
Fix a kernel bug (vmware boot problem) reported by Tomasz Grobelny, which occurs with certain .config variants and gccs. The x86 TLS cleanup in commit efd1ca52d04d2f6df337a3332cee56cd60e6d4c4 made the sys_set_thread_area and sys_get_thread_area functions ripe for tail call optimization. If the compiler chooses to use it for them, it can clobber the user trap frame because these are asmlinkage functions. Reported-by: Tomasz Grobelny <tomasz@grobelny.oswiecenia.net> Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: fix boot failure on 486 due to TSC breakageMikael Pettersson
> Diffing dmesg between git7 and git8 doesn't sched any light since > git8 also removed the printouts of the x86 caps as they were being > initialised and updated. I'm currently adding those printouts back > in the hope of seeing where and when the caps get broken. That turned out to be very illuminating: --- dmesg-2.6.24-git7 2008-02-24 18:01:25.295851000 +0100 +++ dmesg-2.6.24-git8 2008-02-24 18:01:25.530358000 +0100 ... CPU: After generic identify, caps: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000 CPU: After all inits, caps: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000 +CPU: After applying cleared_cpu_caps, caps: 00000013 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Notice how the TSC cap bit goes from Off to On. (The first two lines are printout loops from -git7 forward-ported to -git8, the third line is the same printout loop added just after the xor-with-cleared_cpu_caps[] loop.) Here's how the breakage occurs: 1. arch/x86/kernel/tsc_32.c:tsc_init() sees !cpu_has_tsc, so bails and calls setup_clear_cpu_cap(X86_FEATURE_TSC). 2. include/asm-x86/cpufeature.h:setup_clear_cpu_cap(bit) clears the bit in boot_cpu_data and sets it in cleared_cpu_caps 3. arch/x86/kernel/cpu/common.c:identify_cpu() XORs all caps in with cleared_cpu_caps HOWEVER, at this point c->x86_capability correctly has TSC Off, cleared_cpu_caps has TSC On, so the XOR incorrectly sets TSC to On in c->x86_capability, with disastrous results. The real bug is that clearing bits with XOR only works if the bits are known to be 1 prior to the XOR, and that's not true here. A simple fix is to convert the XOR to AND-NOT instead. The following patch does that, and allows my 486 to boot 2.6.25-rc kernels again. [ mingo@elte.hu: fixed a similar bug in setup_64.c as well. ] The breakage was introduced via commit 7d851c8d3db0. Signed-off-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: fix build on non-C locales.Priit Laes
For some locales regex range [a-zA-Z] does not work as it is supposed to. so we have to use [:alnum:] and [:xdigit:] to make it work as intended. [1] http://en.wikipedia.org/wiki/Estonian_alphabet Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: make c_idle.work have a static address.Glauber Costa
Currently, c_idle is declared in the stack, and thus, have no static address. Peter Zijlstra points out this simple solution, in which c_idle.work is initializated separatedly. Note that the INIT_WORK macro has a static declaration of a key inside. Signed-off-by: Glauber Costa <gcosta@redhat.com> Acked-by: Peter Zijlstra <pzijlstr@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: don't save unreliable stack trace entriesVegard Nossum
Currently, there is no way for print_stack_trace() to determine whether a given stack trace entry was deemed reliable or not, simply because save_stack_trace() does not record this information. (Perhaps needless to say, this makes the saved stack traces A LOT harder to read, and probably with no other benefits, since debugging features that use save_stack_trace() most likely also require frame pointers, etc.) This patch reverts to the old behaviour of only recording the reliable trace entries for saved stack traces. Signed-off-by: Vegard Nossum <vegardno@ifi.uio.no> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: don't make swapper_pg_pmd globalAdrian Bunk
There doesn't seem to be any reason for swapper_pg_pmd being global. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: don't print a warning when MTRR are blank and running in KVMJoerg Roedel
Inside a KVM virtual machine the MTRRs are usually blank. This confuses Linux and causes a warning message at boot. This patch removes that warning message when running Linux as a KVM guest. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-02-26x86: fix execve with -fstack-protectIngo Molnar
pointed out by pageexec@freemail.hu: > what happens here is that gcc treats the argument area as owned by the > callee, not the caller and is allowed to do certain tricks. for ssp it > will make a copy of the struct passed by value into the local variable > area and pass *its* address down, and it won't copy it back into the > original instance stored in the argument area. > > so once sys_execve returns, the pt_regs passed by value hasn't at all > changed and its default content will cause a nice double fault (FWIW, > this part took me the longest to debug, being down with cold didn't > help it either ;). To fix this we pass in pt_regs by pointer. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-04 22:05:30 +0000