Impact: cleanup
disable_ioapic_setup() in init/main.c is ugly as the function is
x86-specific. The #ifdef inline prototype there is ugly too.
Replace it with a generic arch_disable_smp_support() function - which
has a weak alias for non-x86 architectures and for non-ioapic x86 builds.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Most of the vector layout on 32-bit and 64-bit is identical now,
so eliminate the duplicated enumeration of the vectors.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Add a slot for the performance monitoring interrupt. Not yet used
by any subsystem - but the hardware has it. (This eases integration
with performance monitoring code.)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix rare crash on 32-bit
The 32-bit APIC drivers had their send_IPI_self vectors set to NULL,
but ioapic_retrigger_irq() depends on it being always set. Fix it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
just like 64 bit switch from flat logical APIC messages to
flat physical mode automatically.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: 32-bit should use logical version
there are two version: for default_send_IPI_mask_sequence/allbutself
one in ipi.h and one in ipi.c for 32bit
it seems .h version overwrote ipi.c for a while.
restore it so 32 bit could use its old logical version.
also remove dupicated functions in .c
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
X86_PC is the only remaining 'sub' architecture, so we dont need
it anymore.
This also cleans up a few spurious references to X86_PC in the
driver space - those certainly should be X86.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
xapic fix for 32bit platform with less than 8 cpu's.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
X86_GENERICARCH is a misnomer - it contains non-PC 32-bit architectures
that are not included in the default build.
Rename it to X86_32_NON_STANDARD.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_VSMP out of the subarch menu - this way it can be enabled
together with standard PC support as well, in the same kernel.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
- make X86_GENERICARCH depend X86_NON_STANDARD
- move X86_SUMMIT, X86_ES7000 and X86_BIGSMP out of the subarchitecture
menu and under this option
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_ELAN (old, NCR hw platform built on Intel CPUs) from the
subarchitecture menu to the non-standard-platform section.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_ELAN (old, AMD based web-boxes) from the subarchitecture
menu to the non-standard-platform section.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this ISA quirk (because Voyager has no ISA support):
config ISA
bool "ISA support"
depends on !X86_VOYAGER
There's a ton of x86 hardware that does not support ISA, and because
most ISA drivers cannot auto-detect in a safe way, the convention in
the kernel has always been to not enable ISA drivers if they are not
needed.
Voyager users can do likewise - no need for a Kconfig quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this PM/ACPI Kconfig quirk:
menu "Power management and ACPI options"
depends on !X86_VOYAGER
Most of the PM features are auto-detect so they should be safe to run
on just about any hardware. (If not, those instances need fixing.)
In any case, if a kernel is built for Voyager, the power management
options can be disabled.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this Kconfig quirk:
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP && HOTPLUG && !X86_VOYAGER
But this exception will be moot once Voyager starts using the
generic x86 code.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
If no MCE code is desired on Voyager hw then the solution
is to turn them off in the .config - and to extend the MCE
code to not initialize on Voyager.
Remove the build-time quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The lapic/ioapic code properly auto-detects and is safe to run on CPUs that
have no local APIC. (or which have their lapic turned off in the hardware)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Remove this Kconfig quirk:
config PARAVIRT
bool "Enable paravirtualization code"
depends on !X86_VOYAGER
help
Voyager support built into a kernel does not preclude paravirt support.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this quirk currently:
config KVM_GUEST
bool "KVM Guest support"
select PARAVIRT
depends on !X86_VOYAGER
Voyager support built into a kernel image does not exclude
KVM paravirt guest support - so remove this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this build-time quirk to exclude KVM_CLOCK:
bool "KVM paravirtualized clock"
select PARAVIRT
select PARAVIRT_CLOCK
depends on !X86_VOYAGER
Voyager support built into a kernel image does not exclude
KVM paravirt clock support - so remove this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager has this build-time quirk:
bool "VMI Guest support"
select PARAVIRT
depends on X86_32
depends on !X86_VOYAGER
Since VMI is auto-detected (and Voyager will be auto-detected) there's no
reason for this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager had this Kconfig quirk:
config X86_FIND_SMP_CONFIG
def_bool y
depends on X86_MPPARSE || X86_VOYAGER
Which splits off the find_smp_config() callback into a build-time quirk.
Voyager should use the existing x86_quirks.mach_find_smp_config() callback
to introduce SMP-config quirks. NUMAQ-32 and VISWS already use this.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this Kconfig quirk:
config X86_BIOS_REBOOT
bool
depends on !X86_VOYAGER
default y
Voyager should use the existing machine_ops.emergency_restart reboot
quirk mechanism instead of a build-time quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this Kconfig quirk:
depends on (X86_32 && !X86_VOYAGER) || X86_64
That is unnecessary as HT support is CPUID driven and explicitly
enumerated.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager can boot on non-zero processors. While that can probably
be fixed by properly remapping the physical CPU IDs, keep boot_cpu_id
for now for easier transition - and expand it to all of x86.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The x86/Voyager subarch used to have this distinction between
'x86 SMP support' and 'Voyager SMP support':
config X86_SMP
bool
depends on SMP && ((X86_32 && !X86_VOYAGER) || X86_64)
This is a pointless distinction - Voyager can (and already does) use
smp_ops to implement various SMP quirks it has - and it can be extended
more to cover all the specialities of Voyager.
So remove this complication in the Kconfig space.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this Kconfig quirk for suspend/resume:
config ARCH_SUSPEND_POSSIBLE
def_bool y
depends on !X86_VOYAGER
The proper mechanism to not suspend on a piece of hardware to disable
CONFIG_SUSPEND. Remove the quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this hibernation quirk:
config ARCH_HIBERNATION_POSSIBLE
def_bool y
depends on !SMP || !X86_VOYAGER
Hibernation is a generic facility provided on all x86 platforms. If it
is buggy on Voyager then that bug should be fixed - not worked around.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager has this KGDB quirk:
select HAVE_ARCH_KGDB if !X86_VOYAGER
This is completely pointless - there's nothing in KGDB that cannot work
on Voyager. Remove it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager and other subarchitectures have this Kconfig quirk:
select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
This is unnecessary, as KVM cleanly detects based on CPUID capabilities.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager has this quirk for SCx200 support:
config SCx200
tristate "NatSemi SCx200 support"
depends on !X86_VOYAGER
Remove it - Voyager users can disable drivers they dont need.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Remove Voyager Kconfig quirk: just like any other hardware platform
users of Voyager systems can configure in the hardware drivers they need.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager does not build right now and it's unclear whether it will
be cleaned up and ported to the subarch-less 32-bit x86 code - so disable
it for now.
If it's fixed we'll re-enable it - or remove it after some time. There's
a very low number of systems running development kernels on x86/Voyager
currently. (one or two on the whole planet)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Ingo Molnar
Yinghai Lu
Suresh Siddha