lkml.org 
[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: APIC version and 8-bit APIC IDs
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/

\
 
 \ /
  Last update: 2005-08-31 15:16    [W:0.073 / U:3.276 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site