| 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
| ||
|
Message-ID: <53DB3877.3010909@linaro.org>
Date: Fri, 01 Aug 2014 14:49:27 +0800
From: Hanjun Guo <hanjun.guo@...aro.org>
To: Geoff Levand <geoff@...radead.org>
CC: Catalin Marinas <catalin.marinas@....com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Mark Rutland <mark.rutland@....com>,
Mark Brown <broonie@...aro.org>,
Liviu Dudau <Liviu.Dudau@....com>,
Lv Zheng <lv.zheng@...el.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Robert Moore <robert.moore@...el.com>,
linux-acpi@...r.kernel.org, Grant Likely <grant.likely@...aro.org>,
Charles.Garcia-Tobin@....com, Robert Richter <rric@...nel.org>,
Jason Cooper <jason@...edaemon.net>,
Arnd Bergmann <arnd@...db.de>,
Marc Zyngier <marc.zyngier@....com>,
Will Deacon <will.deacon@....com>,
Tomasz Nowicki <tomasz.nowicki@...aro.org>,
Olof Johansson <olof@...om.net>,
Bjorn Helgaas <bhelgaas@...gle.com>,
linux-arm-kernel@...ts.infradead.org,
Graeme Gregory <graeme.gregory@...aro.org>,
Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org, Sudeep Holla <Sudeep.Holla@....com>
Subject: Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization
in ACPI way
On 2014-8-1 2:52, Geoff Levand wrote:
> Hi Hanjun,
Hi Geoff,
>
> On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@...aro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@...aro.org>
>> ---
>> arch/arm64/include/asm/acpi.h | 21 +++++++++++++++
>> arch/arm64/include/asm/cpu_ops.h | 9 ++++++-
>> arch/arm64/include/asm/smp.h | 2 +-
>> arch/arm64/kernel/acpi.c | 9 +++++++
>> arch/arm64/kernel/cpu_ops.c | 52 ++++++++++++++++++++++++++++++++++----
>> arch/arm64/kernel/smp.c | 29 +++++++++++++++++++--
>> 6 files changed, 113 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5ce85f8..6240327 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -14,6 +14,27 @@
>>
>> /* Basic configuration for ACPI */
>> #ifdef CONFIG_ACPI
>
> ^^ This seems to be a tab (\t) character here, which is a strange thing
> for me to see...
Yes, seems to be a tab but actually not :)
>
>> +/*
>> + * ACPI 5.1 only has two explicit methods to
>> + * boot up SMP, PSCI and Parking protocol,
>> + * but the Parking protocol is only defined
>> + * for ARMv7 now, so make PSCI as the only
>> + * way for the SMP boot protocol before some
>> + * updates for the ACPI spec or the Parking
>> + * protocol spec.
>> + *
>> + * This enum is intend to make the boot method
>> + * scalable when above updates are happended,
>> + * which NOT means to support all of them.
>> + */
>
> This comment will become out of date soon (I hope), and it is often the
> case that these short term comments are not removed, so I think it
> better to put this kind of note into the commit message, not the code.
This will need some time, the spec is not ready and we still need more time
for people to implement Parking protocol, I think we can keep this comments
until Parking protocol driver is ready, and update them at that time.
>
>> +enum acpi_smp_boot_protocol {
>> + ACPI_SMP_BOOT_PSCI,
>> + ACPI_SMP_BOOT_PARKING_PROTOCOL,
>> + ACPI_SMP_BOOT_PROTOCOL_MAX
>> +};
>> +
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
>> +
>> extern int acpi_disabled;
>> extern int acpi_noirq;
>> extern int acpi_pci_disabled;
>> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
>> index d7b4b38..2a7c6fd 100644
>> --- a/arch/arm64/include/asm/cpu_ops.h
>> +++ b/arch/arm64/include/asm/cpu_ops.h
>> @@ -61,7 +61,14 @@ struct cpu_operations {
>> };
>>
>> extern const struct cpu_operations *cpu_ops[NR_CPUS];
>> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
>> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
>> +
>> +#ifdef CONFIG_ACPI
>> +extern int __init cpu_acpi_read_ops(int cpu);
>> +#else
>> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
>> +#endif
>
> This looks messy and not scalable for new enable methods. It
> seems a better way is to retain cpu_read_ops() and its functionality,
> which is to return the proper enable method for that cpu in a generic
> way.
>
> Is there some reason you can't integrate acpi into the existing
> cpu_ops and need to make this completely parallel method?
>
>> extern void __init cpu_read_bootcpu_ops(void);
>>
>> #endif /* ifndef __ASM_CPU_OPS_H */
>> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
>> index a498f2c..a5cea56 100644
>> --- a/arch/arm64/include/asm/smp.h
>> +++ b/arch/arm64/include/asm/smp.h
>> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>> extern void handle_IPI(int ipinr, struct pt_regs *regs);
>>
>> /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>> */
>> extern void smp_init_cpus(void);
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>> return 0;
>> }
>>
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> + if (acpi_psci_present)
>> + return ACPI_SMP_BOOT_PSCI;
>> + else
>> + return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>> static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> {
>> struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>> * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> */
>>
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>> #include <linux/errno.h>
>> #include <linux/of.h>
>> #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
>>
>> extern const struct cpu_operations smp_spin_table_ops;
>> extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>> /*
>> * Read a cpu's enable method from the device tree and record it in cpu_ops.
>> */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>> {
>> const char *enable_method = of_get_property(dn, "enable-method", NULL);
>> if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> + /*
>> + * For ACPI 5.1, only two kind of methods are provided,
>> + * Parking protocol and PSCI, but Parking protocol is
>> + * used on ARMv7 only, so make PSCI as the only method
>> + * for SMP initialization before the ACPI spec or Parking
>> + * protocol spec is updated.
>> + */
>
> Again, this comment will get old fast (I hope).
>
>> + switch (smp_boot_protocol()) {
>> + case ACPI_SMP_BOOT_PSCI:
>> + cpu_ops[cpu] = cpu_get_ops("psci");
>> + break;
>> + case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> + default:
>> + cpu_ops[cpu] = NULL;
>> + break;
>> + }
>> +
>> + if (!cpu_ops[cpu]) {
>> + pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> + cpu);
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> void __init cpu_read_bootcpu_ops(void)
>> {
>> - struct device_node *dn = of_get_cpu_node(0, NULL);
>> + struct device_node *dn;
>> +
>> + if (!acpi_disabled) {
>> + cpu_acpi_read_ops(0);
>> + return;
>> + }
>> +
>> + dn = of_get_cpu_node(0, NULL);
>> if (!dn) {
>> pr_err("Failed to find device node for boot cpu\n");
>> return;
>> }
>> - cpu_read_ops(dn, 0);
>> + cpu_of_read_ops(dn, 0);
>> }
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 8f1d37c..cb71662 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>> * cpu logical map array containing MPIDR values related to logical
>> * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>> */
>> -void __init smp_init_cpus(void)
>> +static void __init of_smp_init_cpus(void)
>> {
>> struct device_node *dn = NULL;
>> unsigned int i, cpu = 1;
>> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>> if (cpu >= NR_CPUS)
>> goto next;
>>
>> - if (cpu_read_ops(dn, cpu) != 0)
>> + if (cpu_of_read_ops(dn, cpu) != 0)
>> goto next;
>>
>> if (cpu_ops[cpu]->cpu_init(dn, cpu))
>> @@ -418,6 +418,31 @@ next:
>> set_cpu_possible(i, true);
>> }
>>
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> + int cpu;
>> +
>> + for_each_possible_cpu(cpu) {
>> + if (cpu_acpi_read_ops(cpu) != 0)
>> + continue;
>> +
>> + cpu_ops[cpu]->cpu_init(NULL, cpu);
>> + }
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> + if (acpi_disabled)
>> + of_smp_init_cpus();
>> + else
>> + acpi_smp_init_cpus();
>> +}
>
> This is the same as cpu_ops, is acpi so special we need a completely
> parallel method of initializing secondary cpus?
Good point, Olof suggested the same here, I'm working on it and try to
implement the code as you suggested, if I can't I will comment on it for
the reasons that why I can't make it.
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