Messages in this thread | | | Date | Wed, 14 Mar 2012 21:18:18 +0100 | From | Steffen Persvold <> | Subject | Re: [PATCH] Move APIC ID validity check into platform APIC code |
| |
On 3/14/2012 18:58, Yinghai Lu wrote: > On Wed, Mar 14, 2012 at 12:17 AM, Daniel J Blueman [] > > can you check if you can update > > !cpu_has_x2apic&& (apic_id>= 0xff)&& enabled > > in arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() > > to use some kind of apic_id_valid() > > so you could avoid setting that feature bit. > > the checking in SRAT could be removed. >
Yinghai/Team,
One question (as I don't really know *why* this was added to the acpi/srat parsing code). In arch/x86/kernel/smpboot.c the check was originally :
!x2apic_mode && apicid >= 255
However in arch/x86/kernel/acpi/boot.c and arch/x86/mm/srat.c these tests are used :
!cpu_has_x2apic && (apic_id >= 0xff)
Clearly, "cpu_has_x2apic" and "x2apic_mode" are two different things.
Since we can force "cpu_has_x2apic", when Daniel crafted this patch he made the following "default" function :
static inline int default_apic_id_valid(int apicid) { return x2apic_mode || (apicid < 255); }
which, as you can see, checks against "x2apic_mode".
My question is; Is checking for "x2apic_mode" going to do the trick in the arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() ?
If the answer is yes, the patch is going to be very simple. But we can't verify that the code in arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() actually triggers for the case you wanted it to trigger for because then it will check against "x2apic_mode" and not "cpu_has_x2apic".
Cheers, -- Steffen Persvold, Chief Architect NumaChip Numascale AS - www.numascale.com Tel: +47 92 49 25 54 Skype: spersvold
| |