Re: UP APIC reenabling vs. cpu type detection ordering

From: Mikael Pettersson (
Date: Wed Feb 07 2001 - 12:35:58 EST

H. Peter Anvin writes:
> > if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
> > printk("No APIC support for non-Intel processors.\n");
> > return -1;
> > }
> Why is the test there in the first place? If the machine has an APIC, it
> should be able to use it. Presumably no other CPU uses the same MSR
> address (am I wrong?) for anything else -- if so, it should be able to
> poke it as long as the kernel intercepts the #GP(0) that may come if it
> is not enabled. The Linux kernel has pretty sophisticated support for
> trapping faults.

The reason is that AMD so far has put relevant documentation about (a) what
the local APIC itself looks like, and (b) how to enable it, under NDA.

Having "apic" in your feature bits doesn't imply that the APIC_BASE MSR
is supported, or is at the same MSR index, or hasn't changed subtly.
So the test there is saying "unless we KNOW how to do it, don't try".

(Now thanks to tests done by Petr and others, it does appear that the
K7 local APIC is pretty much compatible with the P6 one. But we didn't
know this until very recently.)

> In other words, I'd like to see a reason for making any vendor-specific
> determinations, and if so, they should ideally be centralized to the CPU
> feature-determination code.

The Pentium 4 has a local APIC. It's not 100% compatible with the P6, and
you sometimes have to know which one you're poking. CPUID returns the
APIC feature bit. Should we mask its APIC capability? Of course not.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 07 2001 - 21:00:27 EST