From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6FC92459E5 for ; Fri, 14 Nov 2025 16:16:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763137013; cv=none; b=USVfIa9tVp5mBO9EUvr8/Dl4BnlYQkHnXovQt2CgwgZCpOqsJMLLfYB/wVQ+4r/Dx1OFyfKOHNXgZqNqkc8m/4B9RoGxOI0iWbuDItB3sf+uVNwsXE5X4nzeAnFmK0e4anWGPD1GtQM9LhtOKV/VgDjdD6BNL2Dmtcj/7cFC6sE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763137013; c=relaxed/simple; bh=w2t1mA6rwEW9DIgDfr9/oJgqaIJ0lRtOyBi8MuitgL4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l7LgHyJTdy78kwmK6WUewFr+6wV+qk4sDcfYDB4idiqOcgUd9ZjKXsQPhxNQukEKD/PEN/FL/UrHLFpFzCjc0R8eG8e3p3Zj5UzogTOymUuqqgSW2gyjh9uJoLrndEfW5zuSEWw/av+f/U4sSBB7yINrrP6/q5vGkyw15hmGlu8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MXswRlHG; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MXswRlHG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763137012; x=1794673012; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=w2t1mA6rwEW9DIgDfr9/oJgqaIJ0lRtOyBi8MuitgL4=; b=MXswRlHG8ZBrReV8PxhFGiKsNJVGSWTputLiZoJWQYuiwHmEIX9etFjv vaUigX50fOcDrsyg2Ee8aYoFYYkanWoToJtq2GlsnNU8G1mxRBpKu3V1S pCjApMSnf1YYTxcmn0jZRabwesQjnqh2DNgFB7x271KUiYv+5rOZq5Pfg w3ixgXBjvgGz5lN58WZ+t/z6cWVzdiiZ7wDprCeoiGBsxsZmHpryu9TKG V4NuVCYBH3Mz2/9Qe8t2QgQUQ2u0qEa/DkuYJaQvGMtPtrwEgboktq4XD CI1sA1f97qHNRXGGmQPk1Hwz6JquFC26B0iSz+6jVKLmG/J801qDFGaG6 w==; X-CSE-ConnectionGUID: SmcmDqqMSfuKY9/E99lm5w== X-CSE-MsgGUID: vdCbU/ulS7iBcwihEqQIsQ== X-IronPort-AV: E=McAfee;i="6800,10657,11613"; a="75555829" X-IronPort-AV: E=Sophos;i="6.19,305,1754982000"; d="scan'208";a="75555829" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2025 08:16:52 -0800 X-CSE-ConnectionGUID: BTYZvSa+QAqc8/KCpELYhQ== X-CSE-MsgGUID: inV7FlwRT4mW0LghDZQv7w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,305,1754982000"; d="scan'208";a="189080163" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa006.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2025 08:16:51 -0800 Date: Fri, 14 Nov 2025 08:23:58 -0800 From: Ricardo Neri To: Yazen Ghannam Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Michal Pecio , Eric DeVolder , Mario Limonciello Subject: Re: [PATCH] x86/acpi/boot: Correct acpi_is_processor_usable() check again Message-ID: <20251114162358.GA31707@ranerica-svr.sc.intel.com> References: <20251111145357.4031846-1-yazen.ghannam@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251111145357.4031846-1-yazen.ghannam@amd.com> User-Agent: Mutt/1.9.4 (2018-02-28) On Tue, Nov 11, 2025 at 02:53:57PM +0000, Yazen Ghannam wrote: > ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is > used in conjunction with the "Enabled" MADT LAPIC flag to determine if a > CPU can be enabled/hotplugged by the OS after boot. > > Before the new bit was defined, the "Enabled" bit was explicitly > described like this (ACPI v6.0 wording provided): > "If zero, this processor is unusable, and the operating system > support will not attempt to use it" > > This means that CPU hotplug (based on MADT) is not possible. Many BIOS > implementations follow this guidance. They may include LAPIC entries in > MADT for unavailable CPUs, but since these entries are marked with > "Enabled=0" it is expected that the OS will completely ignore these > entries. > > However, QEMU will do the same (include entries with "Enabled=0") for > the purpose of allowing CPU hotplug within the guest. > > Comment from QEMU function pc_madt_cpu_entry(): > /* ACPI spec says that LAPIC entry for non present > * CPU may be omitted from MADT or it must be marked > * as disabled. However omitting non present CPU from > * MADT breaks hotplug on linux. So possible CPUs > * should be put in MADT but kept disabled. > */ > > Recent Linux topology changes broke the QEMU use case. A following fix > for the QEMU use case broke bare metal topology enumeration. > > Rework the Linux MADT LAPIC flags check to allow the QEMU use case only > for guests and to maintain the ACPI spec behavior for bare metal. > > Remove an unnecessary check added to fix a bare metal case introduced by > the QEMU "fix". > > Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check") > Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package") > Reported-by: Michal Pecio > Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com > Signed-off-by: Yazen Ghannam > Cc: stable@vger.kernel.org > Cc: Eric DeVolder > Cc: Mario Limonciello > --- > > Notes: > Link: > https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com > > Hi all, > > This patch came out of the discussion above. > > A number of folks (myself included) understood the ACPI MADT LAPIC > "Enabled" flag to be potentially used for CPU hotplug. This is > explicitly false based on the wording in older revisions of the ACPI > spec. > > However, this understanding is used for QEMU. Hence we need a check to > differentiate the virtualization and bare metal use cases. > > Thanks, > Yazen Tested-by: Ricardo Neri I tested this on a 4-socket Cascade Lake server with a BIOS based on ACPI 6.1. All the lAPIC structures had the Enable bit set. It booted successfully.