Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-Id: <5AE2CF8802000078001BF017@prv1-mh.provo.novell.com>
Date:   Fri, 27 Apr 2018 01:21:44 -0600
From:   "Jan Beulich" <JBeulich@suse.com>
To:     <douly.fnst@cn.fujitsu.com>, <tglx@linutronix.de>
Cc:     <linux-kernel@vger.kernel.org>
Subject: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from
 being accounted"
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello,

I've just stumbled across this commit, and I'm wondering if that's actually
correct (I too have at least one system where such IDs are reported in
MADT): For offline/absent CPUs, the firmware may not know the APIC IDs
at the point MADT is built, so I think it is quite reasonable to put ~0 in
there. The ACPID spec specifically calls out that the IDs must not change
across sleep states, which implies to me that they may change across an
offline period of a CPU. IOW I think such entries still need to contribute to
the count of disabled CPUs.

I notice a similar change has been done for the xAPIC case a while ago
by you, Thomas.

Jan