Re: UP APIC reenabling vs. cpu type detection ordering

[Mikael Pettersson]

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.

/Mikael