Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935238AbcJFVUf (ORCPT ); Thu, 6 Oct 2016 17:20:35 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:34096 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933642AbcJFVU0 (ORCPT ); Thu, 6 Oct 2016 17:20:26 -0400 MIME-Version: 1.0 In-Reply-To: <4608f474-c49e-550b-90e2-c5f4c25e00f5@cn.fujitsu.com> References: <1472114120-3281-4-git-send-email-douly.fnst@cn.fujitsu.com> <4608f474-c49e-550b-90e2-c5f4c25e00f5@cn.fujitsu.com> From: Yinghai Lu Date: Thu, 6 Oct 2016 14:20:24 -0700 X-Google-Sender-Auth: P0jgvA3iOuN7y7RgVtt3xcyNRAw Message-ID: Subject: Re: [tip:x86/apic] x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping To: Dou Liyang Cc: Thomas Gleixner , Linux Kernel Mailing List , Ingo Molnar , "H. Peter Anvin" , "linux-tip-commits@vger.kernel.org" , Tony Luck Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1646 Lines: 54 On Thu, Oct 6, 2016 at 1:06 AM, Dou Liyang wrote: > I seem to remember that in x2APIC Spec the x2APIC ID may be at 255 or > greater. Good to know. Maybe later when one package have more cores like 30 cores etc. > If we do that judgment, it may be affect x2APIC's work in some other places. > > I saw the MADT, the main reason may be that we define 0xff to acpi_id > in LAPIC mode. > As you said, it was like: > [ 42.107902] ACPI: LAPIC (acpi_id[0xff] lapic_id[0xff] disabled) > [ 42.120125] ACPI: LAPIC (acpi_id[0xff] lapic_id[0xff] disabled) > [ 42.132361] ACPI: LAPIC (acpi_id[0xff] lapic_id[0xff] disabled) > ... > > How about doing the acpi_id check when we parse it in > acpi_parse_lapic(). > > 8<---------------- > > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -233,6 +233,11 @@ acpi_parse_lapic(struct acpi_subtable_header * header, > const unsigned long end) > > acpi_table_print_madt_entry(header); > > + if (processor->id >= 255) { > + ++disabled_cpus; > + return -EINVAL; > + } > + > /* > * We need to register disabled CPU as well to permit > * counting disabled CPUs. This allows us to size Yes, that should work. but should do the same thing for x2apic in acpi_parse_x2apic should have > + if (processor->local_apic_id == -1) { > + ++disabled_cpus; > + return -EINVAL; > + } that is the reason why i want to extend acpi_register_lapic() to take extra disabled_id (one is 0xff and another is 0xffffffff) so could save some lines. Thanks Yinghai