From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757509AbeD0HVr convert rfc822-to-8bit (ORCPT ); Fri, 27 Apr 2018 03:21:47 -0400 Received: from prv1-mh.provo.novell.com ([137.65.248.33]:46256 "EHLO prv1-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753480AbeD0HVq (ORCPT ); Fri, 27 Apr 2018 03:21:46 -0400 Message-Id: <5AE2CF8802000078001BF017@prv1-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 18.0.0 Date: Fri, 27 Apr 2018 01:21:44 -0600 From: "Jan Beulich" To: , Cc: 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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