ACK: [SRU][N, O][PATCH v2 0/1] x86/acpi: Fix LAPIC/x2APIC parsing order
Masahiro Yamada
masahiro.yamada at canonical.com
Mon Feb 10 03:36:47 UTC 2025
On Fri, Feb 7, 2025 at 7:09 PM Robert Malz <robert.malz at canonical.com> wrote:
>
> [ Impact ]
>
> * In Kernels with commit ec9aedb2aa1a (6.7) CPUs can be enumerated in the order
> which violates ACPI specification that states:
> "OSPM should initialize processors in the order that they appear in the MADT"
>
> * The problematic commit parses all LAPIC entries before any x2APIC
> entries, aiming to ignore x2APIC entries with APIC ID < 255 when valid
> LAPIC entries exist. However, it disrupts the CPU enumeration order on
> systems where x2APIC entries precede LAPIC entries in the MADT.
>
> * In scenarios with strict CPU pinning this behavior might introduce
> performance degradation or hyperthreading related side-channel
> vulnerabilities
>
> * Issue has been fixed upstream with commit 0141978ae75
>
> [ Test Plan ]
>
> * Issue reproduces only in specific ACPI MADT configurations with
> mixed LAPIC and x2APIC entries. An example of it would be AMD Genoa CPUs.
>
> * Easiest way to reproduce it locally is to replace x2APIC entry
> before LAPIC in MADT table.
> Steps to reproduce (local VM):
> 1. Set up a VM with 288 vCPUs
> sudo qemu-system-x86_64 -enable-kvm \
> -M q35,accel=kvm,kernel-irqchip=split \
> -device intel-iommu,intremap=on \
> -smp 288,cores=144,threads=1,sockets=2 \
> -m 20G \
> -cpu host \
> -object memory-backend-ram,id=mem0,size=10G \
> -object memory-backend-ram,id=mem1,size=10G \
> -numa node,cpus=0-143,nodeid=0,memdev=mem0 \
> -numa node,cpus=144-287,nodeid=1,memdev=mem1 \
> -drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
> -boot d
> 2. Dump acpi apic/madt tables from VM
> acpidump > acpidump.dat
> acpixtract -a acpidump.dat
> iasl -d apic.dat
> ----
> apic.dsl file will be generated.
> 3. Craft apic.dsl and switch order of CPUs
> 4. Compile apic.dsl to aml file
> iasl -tc apic.dsl
> 5. Inject new table to VM
> sudo qemu-system-x86_64 -enable-kvm \
> -M q35,accel=kvm,kernel-irqchip=split \
> -device intel-iommu,intremap=on \
> -smp 288,cores=144,threads=1,sockets=2 \
> -acpitable file=apic.aml \
> -m 20G \
> -cpu host \
> -object memory-backend-ram,id=mem0,size=10G \
> -object memory-backend-ram,id=mem1,size=10G \
> -numa node,cpus=0-143,nodeid=0,memdev=mem0 \
> -numa node,cpus=144-287,nodeid=1,memdev=mem1 \
> -drive file=/var/lib/libvirt/images/ubuntu24.04.qcow2,format=qcow2 \
> -boot d
> Results:
> Depending on MADT changes. For following example I have moved single x2APIC entry
> after the first LAPIC.
> Incorrect enumeration present on 6.8 Kernels:
> NUMA node(s): 2
> NUMA node0 CPU(s): 0-143
> NUMA node1 CPU(s): 144-287
> Enumeration on 6.8 Kernel with applied fixes:
> NUMA node(s): 2
> NUMA node0 CPU(s): 0,2-144
> NUMA node1 CPU(s): 1,145-287
>
> [ Where problems could occur ]
>
> * Fix has been tested using alocal VM with a modified MADT table.
>
> * MADT table can have multiple possible configurations, making it hard to
> fully test the fix.
>
> * Potential regression with CPU enumeration can be hard to detect as was in case of
> patch that introduced the issue.
>
> [ Other Info ]
>
> * Patch which introduced an issue: ec9aedb2aa1ab7ac420c00b31f5edc5be15ec167
>
> * Patch fixing the issue: 0141978ae75bd48bac13fca6de131a5071c32011
>
> * Originally issue has been reported for AMD Genoa CPU with following enumeration:
> 6.5.0
> NUMA node(s): 2
> NUMA node0 CPU(s): 0-89,180-269
> NUMA node1 CPU(s): 90-179,270-359
> 6.8.0
> NUMA node(s): 2
> NUMA node0 CPU(s): 0-179
> NUMA node1 CPU(s): 180-359
>
> v2:
> - Changed PATCH 1/X numbering
> - Moved cherry-picked section on top of Signed-off-by
>
>
> Zhang Rui (1):
> x86/acpi: Fix LAPIC/x2APIC parsing order
>
> arch/x86/kernel/acpi/boot.c | 50 +++++++++++++++++++++++++++++++++----
> 1 file changed, 45 insertions(+), 5 deletions(-)
Signed-off-by: Masahiro Yamada <masahiro.yamada at canonical.com>
More information about the kernel-team
mailing list