Re: APIC version and 8-bit APIC IDs

[Martin Wilck <martin.wilck@fujitsu-siemens.com>]

Hi Andi, hi everyone,

> > The MP_valid_apicid() function [arch/i386/kernel/mpparse.c] checks
> > whether the APIC version field is >=20 in order to determine whether
> > the CPU supports 8-bit physical APIC ids.
>
> Yes, it's broken. ... . Also it's only
> a sanity check for broken BIOS, and in this case it causes more problems
> than it solves.

We have another issue with the APIC IDs: the GET_APIC_ID and 
APIC_ID_MASK macros from the subarch code. In all subarchs except summit 
and es7000, these macros use a hard-coded mask 0x0F for the APIC ID. 
Thus, any APIC ID >15 will be truncated, leading to obscure errors.

We are wondering why these masks are there in the subarch code at all. 
After all, whether or not 8-bit APIC IDs are supported depends mainly on 
the CPU type used. Why wouldn't it possible to have a "default" 
architecture with APIC IDs > 15, if the CPUs allow it?

In other words: What would be broken if we just used an APIC ID mask of 
0xFF everywhere?

The current situation with MP_valid_apicid() on the one hand (masking 
the APIC ID as a function of local APIC version) and APIC_ID_MASK 
(masking the APIC as a function of subarch) on the other hand is 
inconsistent. A correct approach must take both CPU and architecture 
constraints into account, and use a CPU-type-dependent variable mask in 
the subarch code.

Regards
Martin

--
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/