aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/Kconfig.cpu
Commit message (Collapse)AuthorAgeFilesLines
* x86: disable static NOPLs on 32 bitsLinus Torvalds2008-09-081-5/+8
| | | | | | | | | | | | | | | On 32-bit, at least the generic nops are fairly reasonable, but the default nops for 64-bit really look pretty sad, and the P6 nops really do look better. So I would suggest perhaps moving the static P6 nop selection into the CONFIG_X86_64 thing. The alternative is to just get rid of that static nop selection, and just have two cases: 32-bit and 64-bit, and just pick obviously safe cases for them. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86: fix crash due to missing debugctlmsr on AMD K6-3Jan Kratochvil2008-07-221-1/+1
| | | | | | | | | | | | | | | | 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> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: APIC: remove apic_write_around(); use alternativesMaciej W. Rozycki2008-07-181-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use alternatives to select the workaround for the 11AP Pentium erratum for the affected steppings on the fly rather than build time. Remove the X86_GOOD_APIC configuration option and replace all the calls to apic_write_around() with plain apic_write(), protecting accesses to the ESR as appropriate due to the 3AP Pentium erratum. Remove apic_read_around() and all its invocations altogether as not needed. Remove apic_write_atomic() and all its implementing backends. The use of ASM_OUTPUT2() is not strictly needed for input constraints, but I have used it for readability's sake. I had the feeling no one else was brave enough to do it, so I went ahead and here it is. Verified by checking the generated assembly and tested with both a 32-bit and a 64-bit configuration, also with the 11AP "feature" forced on and verified with gdb on /proc/kcore to work as expected (as an 11AP machines are quite hard to get hands on these days). Some script complained about the use of "volatile", but apic_write() needs it for the same reason and is effectively a replacement for writel(), so I have disregarded it. I am not sure what the policy wrt defconfig files is, they are generated and there is risk of a conflict resulting from an unrelated change, so I have left changes to them out. The option will get removed from them at the next run. Some testing with machines other than mine will be needed to avoid some stupid mistake, but despite its volume, the change is not really that intrusive, so I am fairly confident that because it works for me, it will everywhere. Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: mark x86_64 as having a working WP.Glauber Costa2008-07-091-1/+1
| | | | | | | | Select X86_WP_WORKS_OK for x86_64 too. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: separate cmpxchg8b checking from PAE checkingJan Beulich2008-05-121-0/+4
| | | | | | | | | .. allowing the former to be use in non-PAE kernels, too. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: CONFIG_X86_ELAN fixIngo Molnar2008-04-301-5/+5
| | | | | | | move the X86_CPU section out of the !X86_ELAN branch. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86, bitops: select the generic bitmap search functionsAlexander van Heukelum2008-04-261-0/+5
| | | | | | | | | | | | | | | | | | Introduce GENERIC_FIND_FIRST_BIT and GENERIC_FIND_NEXT_BIT in lib/Kconfig, defaulting to off. An arch that wants to use the generic implementation now only has to use a select statement to include them. I added an always-y option (X86_CPU) to arch/x86/Kconfig.cpu and used that to select the generic search functions. This way ARCH=um SUBARCH=i386 automatically picks up the change too, and arch/um/Kconfig.i386 can therefore be simplified a bit. ARCH=um SUBARCH=x86_64 does things differently, but still compiles fine. It seems that a "def_bool y" always wins over a "def_bool n"? Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: merge the simple bitops and move them to bitops.hAlexander van Heukelum2008-04-261-1/+1
| | | | | | | | | | | | | | | | | | Some of those can be written in such a way that the same inline assembly can be used to generate both 32 bit and 64 bit code. For ffs and fls, x86_64 unconditionally used the cmov instruction and i386 unconditionally used a conditional branch over a mov instruction. In the current patch I chose to select the version based on the availability of the cmov instruction instead. A small detail here is that x86_64 did not previously set CONFIG_X86_CMOV=y. Improved comments for ffs, ffz, fls and variations. Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: remove NexGen supportDmitri Vorobiev2008-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | It is claimed that NexGen CPUs were never shipped: http://lkml.org/lkml/2008/4/20/179 Also, the kernel support for these chips has been broken for a long time, the code intended to support NexGen thereby being essentially dead. As an outcome of the discussion that can be found using the URL above, this patch removes the NexGen support altogether. The changes in this patch survived a defconfig build for i386, a couple of successful randconfig builds, as well as a runtime test, which consisted in booting a 32-bit x86 box up to the shell prompt. Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: MPSC should use P6 NOPsHugh Dickins2008-04-171-1/+1
| | | | | | | | | | | I've now noticed that the machine I call MPENTIUM4 for 32-bit kernels is called MPSC for 64-bit kernels, and in that case it still doesn't get the P6 NOPs it ought to. hpa explains that MK8 should still be excluded, so it's just a matter of including MPSC along with MPENTIUM4. Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* x86: a P4 is a P6 not an i486Hugh Dickins2008-03-041-1/+1
| | | | | | | 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>
* x86: don't use P6_NOPs if compiling with CONFIG_X86_GENERICH. Peter Anvin2008-02-261-1/+10
| | | | | | | | | | | | | P6_NOPs are definitely not supported on some VIA CPUs, and possibly (unverified) on AMD K7s. It is also the only thing that prevents a 686 kernel from running on Transmeta TM3x00/5x00 (Crusoe) series. The performance benefit over generic NOPs is very small, so when building for generic consumption, avoid using them. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: require family >= 6 if we are using P6 NOPsH. Peter Anvin2008-02-261-0/+5
| | | | | | | | | The P6 family of NOPs are only available on family >= 6 or above, so enforce that in the boot code. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: reduce CONFIG_X86_PPRO_FENCE bloatNick Piggin2008-01-301-1/+10
| | | | | | | | | | | | | | | | | | | | | CONFIG_X86_PPRO_FENCE bloats text: i386 allmodconf: size mm/built-in.o text data bss dec hex text ratio vanilla: 163082 20372 40120 223574 36956 100.00% bugfix : 163509 20372 40120 224001 36b01 0.26% noppro : 162191 20372 40120 222683 365db - 0.55% both : 162267 20372 40120 222759 36627 - 0.50% (+0.05% vs noppro) So with the ppro memory ordering bug out of the way, the PG_uptodate fix only adds 76 bytes of text. allow this config to be specified by distros. [ mingo@elte.hu: x86.git merge ] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: use def_bool where possible in Kconfig.cpuHarvey Harrison2008-01-301-36/+20
| | | | | | | | | | | | | | | x86: Use def_bool where possible in Kconfig.cpu Change occurances of: bool default X to: def_bool X Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: debugctlmsr kconfigRoland McGrath2008-01-301-0/+4
| | | | | | | | | | | | | | This adds the (internal) Kconfig macro CONFIG_X86_DEBUGCTLMSR, to be defined when configuring to support only hardware that definitely supports MSR_IA32_DEBUGCTLMSR with the BTF flag. The Intel documentation says "P6 family" and later processors all have it. I think the Kconfig dependencies are right to have it set for those and unset for others (i.e., when 586 and earlier are supported). Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* x86: arch/x86/Kconfig.cpu unificationSam Ravnborg2007-11-121-46/+75
| | | | | | | | | | | | | | | Move all CPU definitions to Kconfig.cpu Always define X86_MINIMUM_CPU_FAMILY and do the obvious code cleanup in boot/cpucheck.c Comments from: Adrian Bunk <bunk@kernel.org> incorporated. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@kernel.org> Cc: Brian Gerst <bgerst@didntduck.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com>
* x86: move i386 and x86_64 Kconfig files to x86 directorySam Ravnborg2007-10-251-0/+372
After a small change in kconfig Makefile we could move all x86 Kconfig files to x86 directory. Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
generated by cgit v1.1 at 2024-12-26 17:36:24 +0000