linux-kernel - Re: [PATCH -v2] x86, acpi: Handle xapic/x2apic entries in MADT at same time

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] [day] [month] [year] [list]

Date:	Thu, 21 Aug 2014 16:27:42 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -v2] x86, acpi: Handle xapic/x2apic entries in MADT at
 same time

On Thu, Aug 21, 2014 at 12:00 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> (lkml Cc:-ed, in case someone wants to help out.)
>
> The changelog quality and organization of your submitted
> patches is still poor, they are hard to read and review. This
> is a repeat complaint against your patches, yet not much has
> happened over the last few years. Please improve them before
> resending your patches.
>
> As a positive example, here's a couple of x86 architecture
> commits with good changelogs:
>
> 95d76acc7518 ("x86, irq: Count legacy IRQs by legacy_pic->nr_legacy_irqs instead of NR_IRQS_LEGACY")
> 6b9fb7082409 ("x86, ACPI, irq: Consolidate algorithm of mapping (ioapic, pin) to IRQ number")
> 2e0ad0e2c135 ("x86, ACPI, irq: Fix possible error in GSI to IRQ mapping for legacy IRQ")
> 44a69f619562 ("acpi, apei, ghes: Make NMI error notification to be GHES architecture extension")
>
> Please match or exceed the changelog quality of these commits.

How about this version ?

Subject: [PATCH -v3] x86, acpi: Make cpu sequence to be consistent with MADT
From: Yinghai Lu <yinghai@...nel.org>

On 8 socket system that x2apic is pre-enabled, get following sequence:
CPU0: socket0, core0, thread0.
CPU1 - CPU 40: socket 4 - socket 7, thread 0
CPU41 - CPU 80: socket 4 - socket 7, thread 1
CPU81 - CPU 119: socket 0 - socket 3, thread 0
CPU120 - CPU 159: socket 0 - socket 3, thread 1

The system has mixing xapic and x2apic entries in MADT and SRAT.
Current kernel parse all x2apic entries before all xapic entries, and
the same reserve CPU0 slot for boot cpu, so we get out of order
cpu sqeuence.

Some users have scripts that just assume that that cpu sequence is same
as socket0, and then next sockets. According to socket number/core number
in the system, they have simple mapping from kernel cpu index to socket
index.

BIOS guys insist that ACPI 4.0 SPEC says if apic id < 255, even
the cpus are with x2apic mode pre-enabled, still need to use xapic entries
instead of x2apic entries.

We could check every entry in MADT with xapic and x2apic instead of
checking all entries with x2apic then check all entries with xapic.

After patch we have:
CPU0 - CPU 79: socket 0 - socket 7, thread 0
CPU80 - CPU 159: socket 0 - socket 7, thread 1
and we have same cpu sequence as that in MADT.

-v2: update some comments, and change to pass array pointer.
-v3: update changelog.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/