Re: UP APIC reenabling vs. cpu type detection ordering

From: Maciej W. Rozycki (
Date: Wed Feb 07 2001 - 12:55:26 EST

On Wed, 7 Feb 2001, H. Peter Anvin wrote:

> 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 point is whether it is safe to enable the local APIC that was
disabled by BIOS on an unknown CPU. Probably yes, but who knows -- we
might need additional setup to be performed for interrupts to work.

> 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.

 It would be hard to decide how to classify it. It's something like "the
CPU has a local APIC that we know how to handle in the non-MPS system".

 It might be viable just to delete the test altogether, though and just
trap #GP(0) on the MSR access. For the sake of simplicity. If a problem
with a system ever arizes, we may handle it then.

 Note that we still have to choose appropriate vendor-specific PeMo
handling and an event for the NMI watchdog anyway.


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

- 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