linux-kernel - Re: [PATCH] x86/acpi/boot: Correct acpi_is_processor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c430ae05-74ca-4620-bb11-ff40d2eb62f6@amd.com>
Date: Wed, 12 Nov 2025 10:35:13 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Borislav Petkov <bp@...en8.de>, Yazen Ghannam <yazen.ghannam@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
 Michal Pecio <michal.pecio@...il.com>,
 Eric DeVolder <eric.devolder@...cle.com>
Subject: Re: [PATCH] x86/acpi/boot: Correct acpi_is_processor_usable() check
 again

On 11/12/25 7:56 AM, Borislav Petkov wrote:
> 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 <michal.pecio@...il.com>
>> Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com
>> Signed-off-by: Yazen Ghannam <yazen.ghannam@....com>
>> Cc: stable@...r.kernel.org
>> Cc: Eric DeVolder <eric.devolder@...cle.com>
>> Cc: Mario Limonciello <mario.limonciello@....com>
>> ---
>>
>> 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.
> 
> ...
> 
>> +       return (lapic_flags & ACPI_MADT_ONLINE_CAPABLE);
> 
> Superfluous brackets.
> 
> In any case, yah, I'm going to queue this soon but I'll give Eric some time to
> complain before I do.
> 
> I did play with:
> 
> https://www.qemu.org/docs/master/system/cpu-hotplug.html
> 
> and that works with that patch:
> 
> $ ./qmp-shell -p -v localhost:4444
> Welcome to the QMP low-level shell!
> Connected to QEMU 10.1.0
>   
> (QEMU) query-hotpluggable-cpus
> {
>      "arguments": {},
>      "execute": "query-hotpluggable-cpus"
> }
> {
>      "return": [
>          {
>              "props": {
>                  "core-id": 1,
>                  "socket-id": 0,
>                  "thread-id": 0
>              },
>              "type": "host-x86_64-cpu",
>              "vcpus-count": 1
>          },
>          {
>              "props": {
>                  "core-id": 0,
>                  "socket-id": 0,
>                  "thread-id": 0
>              },
>              "qom-path": "/machine/unattached/device[0]",
>              "type": "host-x86_64-cpu",
>              "vcpus-count": 1
>          }
>      ]
> }
> (QEMU) device_add id=cpu-2 driver=host-x86_64-cpu socket-id=0 core-id=1 thread-id=0
> {
>      "arguments": {
>          "core-id": 1,
>          "driver": "host-x86_64-cpu",
>          "id": "cpu-2",
>          "socket-id": 0,
>          "thread-id": 0
>      },
>      "execute": "device_add"
> }
> {
>      "return": {}
> }
> (QEMU)
> 
> and dmesg has:
> 
> [   33.281150] ACPI: acpi_map_cpu: cpu: 1, physid: 0x1, acpi_id: 0x1
> [   33.289650] ACPI: CPU1 has been hot-added
> 
> But man oh man, if this ain't wagging the dog I don't know what is - we're
> fixing the kernel so that qemu can hotplug because, oh well, "but then there
> is this thing called reality^Wvirtualization which ruins everything."...
> 

What version does the MADT in QEMU report today?  Presumably not all 
virtualization solutions make this assumption about this bit.

IE rather than clump all virtualization should we just detect QEMU and < 
ACPI 6.3?