linux-kernel - Re: [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id

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:	Fri, 17 Jan 2014 17:37:37 +0000
From:	Sudeep Holla <Sudeep.Holla@....com>
To:	Hanjun Guo <hanjun.guo@...aro.org>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sudeep.Holla@....com, Matthew Garrett <mjg59@...f.ucam.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	Arnd Bergmann <arnd@...db.de>, Rob Herring <robh@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Olof Johansson <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"patches@...aro.org" <patches@...aro.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set
 and map logical cpu id to APIC id

On 17/01/14 12:25, Hanjun Guo wrote:
> When boot the kernel with MADT, the cpu possible and present sets should
> be enumerated for later smp initialization.
> 
> The logic cpu id maps to APIC id (GIC id) is also implemented, it is
> needed for acpi processor drivers.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    7 ++--
>  drivers/acpi/plat/arm-core.c  |   83 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 87 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c335c6d..7edd39e 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -76,9 +76,6 @@ static inline void acpi_disable_pci(void)
>  /* FIXME: this function should be moved to topology.h when it's ready */
>  void arch_fix_phys_package_id(int num, u32 slot);
>  
> -/* temperally define -1 to make acpi core compilerable */
> -#define cpu_physical_id(cpu) -1
> -
>  /* Low-level suspend routine. */
>  extern int (*acpi_suspend_lowlevel)(void);
>  #define acpi_wakeup_address (0)
> @@ -86,6 +83,10 @@ extern int (*acpi_suspend_lowlevel)(void);
>  #define MAX_GIC_CPU_INTERFACE 256
>  #define MAX_GIC_DISTRIBUTOR   1		/* should be the same as MAX_GIC_NR */
>  
> +/* map logic cpu id to physical GIC id */
> +extern int arm_cpu_to_apicid[NR_CPUS];
> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
> +

You refer arm_cpu_to_apicid as a mapping from logical cpu id to GIC id,
then why is it assigned to cpu_physical_id. cpu_physical_id must be same as
cpu_logical_map which is from logical cpu id to MPIDRs.

[...]

> @@ -321,6 +401,9 @@ int __init early_acpi_boot_init(void)
>  	if (acpi_disabled)
>  		return -ENODEV;
>  
> +	/* Get the boot CPU's GIC cpu interface id before MADT parsing */
> +	boot_cpu_apic_id = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +

Code contradicts your comment. You need GIC cpu interface ID(referred as GIC ID
in the MADT), but you are assigning the MPIDR(physical CPU ID on ARM) to
boot_cpu_apic_id. I think you are assuming GIC ID and MPIDR to be same which is
wrong.

With ACPI5.0, IIUC the only possible way to manage mapping from GIC CPU
interface to MPIDR is to assume(in a way enforce on ARM) ACPI Processor UID in
MADT and CPU Device definition match MPIDR.

Regards,
Sudeep

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