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:[email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |