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]
Date:	Tue, 14 Jul 2015 22:24:10 +0800
From:	Hanjun Guo <hanjun.guo@...aro.org>
To:	Lukasz Anaczkowski <lukasz.anaczkowski@...el.com>,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, jason@...edaemon.net
CC:	rjw@...ysocki.net, len.brown@...el.com, pavel@....cz,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

On 07/14/2015 04:06 PM, Lukasz Anaczkowski wrote:
> On 07/13/2015 23:22 PM, Hanjun Guo wrote:
>>> In case when BIOS is populating MADT wiht both x2apic and local apic
>>> entries (as per ACPI spec), kernel builds it's processor table
>>> in the following order: BSP, X2APIC, local APIC, resulting in
>>> processors on the same core are not separated by core count.
>>
>> I'm confused here, I can't figure out where is the problem, could you
>> explain it in detail?
>>
>> For me, logical CPU IDs allocated by OS will have mappings to physical
>> CPU IDs, what you are saying seems CPU topology problem to me.
>
> Sorry for confusion, I'll send another patch with updated commit message
> where I'll try to put some more details and explanation. Hope that one will
> be less confusing.
>
>>>    arch/x86/kernel/acpi/boot.c | 29 +++++++++++++-----
>>>    drivers/acpi/numa.c         | 28 ++++++++++++-----
>>>    drivers/acpi/tables.c       | 75 ++++++++++++++++++++++++++++-----------------
>>>    drivers/irqchip/irq-gic.c   | 15 ++++++---
>>
>> Anyway, You also miss the SMP boot for ARM64 in ACPI way, which will
>> cause compile error on ARM64.
>
> The only symbol that's changed is acpi_parse_entries and I don't see
> any calls to it in ARM64. I also tried compilation of arm64/defconfig
> and it compiles fine. Could yoy point me to place where it might failing?

Sorry, I misread your patch that you modified acpi_table_parse_madt()
also, but it turns out that you keep it as before, sorry for the noise.

Thanks
Hanjun

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ