Re: [PATCH RFC 05/22] ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv
On 11/7/23 18:29, Russell King (Oracle) wrote:
From: James Morse
Neither arm64 nor riscv support physical hotadd of CPUs that were not
present at boot. For arm64 much of the platform description is in static
tables which do not have update methods. arm64 does support HOTPLUG_CPU,
which is backed by a firmware interface to turn CPUs on and off.
acpi_processor_hotadd_init() and acpi_processor_remove() are for adding
and removing CPUs that were not present at boot. arm64 systems that do this
are not supported as there is currently insufficient information in the
platform description. (e.g. did the GICR get removed too?)
arm64 currently relies on the MADT enabled flag check in map_gicc_mpidr()
to prevent CPUs that were not described as present at boot from being
added to the system. Similarly, riscv relies on the same check in
map_rintc_hartid(). Both architectures also rely on the weak 'always fails'
definitions of acpi_map_cpu() and arch_register_cpu().
Subsequent changes will redefine ACPI_HOTPLUG_CPU as making possible
CPUs present. Neither arm64 nor riscv support this.
Disable ACPI_HOTPLUG_CPU for arm64 and riscv by removing 'default y' and
selecting it on the other three ACPI architectures. This allows the weak
definitions of some symbols to be removed.
Signed-off-by: James Morse
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
Changes since RFC:
* Expanded conditions to avoid ACPI_HOTPLUG_CPU being enabled when
HOTPLUG_CPU isn't.
Changes since RFC v3:
* Dropped ia64 changes
---
arch/loongarch/Kconfig| 1 +
arch/x86/Kconfig | 1 +
drivers/acpi/Kconfig | 1 -
drivers/acpi/acpi_processor.c | 18 --
4 files changed, 2 insertions(+), 19 deletions(-)
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index d889a0b97bc1..64620e90c12c 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -5,6 +5,7 @@ config LOONGARCH
select ACPI
select ACPI_GENERIC_GSI if ACPI
select ACPI_MCFG if ACPI
+ select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
select ACPI_PPTT if ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_BINFMT_ELF_STATE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3762f41bb092..dbdcfc708369 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -59,6 +59,7 @@ config X86
#
select ACPI_LEGACY_TABLES_LOOKUPif ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
+ select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU
select ARCH_32BIT_OFF_T if X86_32
select ARCH_CLOCKSOURCE_INIT
select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f819e760ff19..a3acfc750fce 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -310,7 +310,6 @@ config ACPI_HOTPLUG_CPU
bool
depends on ACPI_PROCESSOR && HOTPLUG_CPU
select ACPI_CONTAINER
- default y
config ACPI_PROCESSOR_AGGREGATOR
tristate "Processor Aggregator"
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 0f5218e361df..4fe2ef54088c 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -184,24 +184,6 @@ static void __init acpi_pcc_cpufreq_init(void) {}
/* Initialization */
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-int __weak acpi_map_cpu(acpi_handle handle,
- phys_cpuid_t physid, u32 acpi_id, int *pcpu)
-{
- return -ENODEV;
-}
-
-int __weak acpi_unmap_cpu(int cpu)
-{
- return -ENODEV;
-}
-
-int __weak arch_register_cpu(int cpu)
-{
- return -ENODEV;
-}
-
-void __weak arch_unregister_cpu(int cpu) {}
-
static int acpi_processor_hotadd_init(struct acpi_processor *pr)
{
unsigned long long sta;
--
Shaoqin
Re: [PATCH RFC 06/22] drivers: base: Use present CPUs in GENERIC_CPU_DEVICES
Hi Russell,
On 11/7/23 18:29, Russell King (Oracle) wrote:
From: James Morse
Three of the five ACPI architectures create sysfs entries using
register_cpu() for present CPUs, whereas arm64, riscv and all
GENERIC_CPU_DEVICES do this for possible CPUs.
Registering a CPU is what causes them to show up in sysfs.
It makes very little sense to register all possible CPUs. Registering
a CPU is what triggers the udev notifications allowing user-space to
react to newly added CPUs.
To allow all five ACPI architectures to use GENERIC_CPU_DEVICES, change
it to use for_each_present_cpu(). Making the ACPI architectures use
GENERIC_CPU_DEVICES is a pre-requisite step to centralise their
cpu_register() logic, before moving it into the ACPI processor driver.
When ACPI is disabled this work would be done by
cpu_dev_register_generic().
What do you actually mean about when ACPI is disabled this work would be
done by cpu_dev_register_generic()? Is the work means register the cpu?
I'm not quite understand that, and how about when ACPI is enabled, which
function do this work?
Of the ACPI architectures that register possible CPUs, arm64 and riscv
do not support making possible CPUs present as they use the weak 'always
fails' version of arch_register_cpu().
Only two of the eight architectures that use GENERIC_CPU_DEVICES have a
distinction between present and possible CPUs.
The following architectures use GENERIC_CPU_DEVICES but are not SMP,
so possible == present:
* m68k
* microblaze
* nios2
The following architectures use GENERIC_CPU_DEVICES and consider
possible == present:
* csky: setup_smp()
* processor_probe() sets possible for all CPUs and present for all CPUs
except the boot cpu, which will have been done by
init/main.c::start_kernel().
um appears to be a subarchitecture of x86.
The remaining architecture using GENERIC_CPU_DEVICES are:
* openrisc and hexagon:
where smp_init_cpus() makes all CPUs < NR_CPUS possible,
whereas smp_prepare_cpus() only makes CPUs < setup_max_cpus present.
After this change, openrisc and hexagon systems that use the max_cpus
command line argument would not see the other CPUs present in sysfs.
This should not be a problem as these CPUs can't bre brought online as
^ nit: can't be
_cpu_up() checks cpu_present().
After this change, only CPUs which are present appear in sysfs.
Signed-off-by: James Morse
Reviewed-by: Jonathan Cameron
Signed-off-by: Russell King (Oracle)
Thanks,
Shaoqin
---
drivers/base/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 9ea22e165acd..34b48f660b6b 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -533,7 +533,7 @@ static void __init cpu_dev_register_generic(void)
#ifdef CONFIG_GENERIC_CPU_DEVICES
int i;
- for_each_possible_cpu(i) {
+ for_each_present_cpu(i) {
if (register_cpu(&per_cpu(cpu_devices, i), i))
panic("Failed to register CPU device");
}
Re: [PATCH RFC 07/22] drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden
On 11/7/23 18:29, Russell King (Oracle) wrote:
From: James Morse
Architectures often have extra per-cpu work that needs doing
before a CPU is registered, often to determine if a CPU is
hotpluggable.
To allow the ACPI architectures to use GENERIC_CPU_DEVICES, move
the cpu_register() call into arch_register_cpu(), which is made __weak
so architectures with extra work can override it.
This aligns with the way x86, ia64 and loongarch register hotplug CPUs
when they become present.
Signed-off-by: James Morse
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
Changes since RFC:
* Dropped __init from x86/ia64 arch_register_cpu()
Changes since RFC v2:
* Dropped unnecessary Loongarch asm/cpu.h changes
---
drivers/base/cpu.c | 14 ++
include/linux/cpu.h | 4
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 34b48f660b6b..579064fda97b 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -525,19 +525,25 @@ bool cpu_is_hotpluggable(unsigned int cpu)
EXPORT_SYMBOL_GPL(cpu_is_hotpluggable);
#ifdef CONFIG_GENERIC_CPU_DEVICES
-static DEFINE_PER_CPU(struct cpu, cpu_devices);
+DEFINE_PER_CPU(struct cpu, cpu_devices);
+
+int __weak arch_register_cpu(int cpu)
+{
+ return register_cpu(&per_cpu(cpu_devices, cpu), cpu);
+}
#endif
static void __init cpu_dev_register_generic(void)
{
-#ifdef CONFIG_GENERIC_CPU_DEVICES
int i;
+ if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
+ return;
+
for_each_present_cpu(i) {
- if (register_cpu(&per_cpu(cpu_devices, i), i))
+ if (arch_register_cpu(i))
panic("Failed to register CPU device");
}
-#endif
}
#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index fc8094419084..1e982d63eae8 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -88,6 +88,10 @@ extern ssize_t arch_cpu_probe(const char *, size_t);
extern ssize_t arch_cpu_release(const char *, size_t);
#endif
+#ifdef CONFIG_GENERIC_CPU_DEVICES
+DECLARE_PER_CPU(struct cpu, cpu_devices);
+#endif
+
/*
* These states are not related to the core CPU hotplug mechanism. They are
* used by various (sub)architectures to track internal state
--
Shaoqin
Re: [PATCH RFC 06/22] drivers: base: Use present CPUs in GENERIC_CPU_DEVICES
On Thu, Nov 09, 2023 at 06:09:32PM +0800, Shaoqin Huang wrote: > Hi Russell, > > On 11/7/23 18:29, Russell King (Oracle) wrote: > > From: James Morse > > > > Three of the five ACPI architectures create sysfs entries using > > register_cpu() for present CPUs, whereas arm64, riscv and all > > GENERIC_CPU_DEVICES do this for possible CPUs. > > > > Registering a CPU is what causes them to show up in sysfs. > > > > It makes very little sense to register all possible CPUs. Registering > > a CPU is what triggers the udev notifications allowing user-space to > > react to newly added CPUs. > > > > To allow all five ACPI architectures to use GENERIC_CPU_DEVICES, change > > it to use for_each_present_cpu(). Making the ACPI architectures use > > GENERIC_CPU_DEVICES is a pre-requisite step to centralise their > > cpu_register() logic, before moving it into the ACPI processor driver. > > When ACPI is disabled this work would be done by > > cpu_dev_register_generic(). > > What do you actually mean about when ACPI is disabled this work would be Firstly, please note that "you" is not appropriate here. This is James' commit message, not mine. > done by cpu_dev_register_generic()? Is the work means register the cpu? When ACPI is disabled _and_ CONFIG_GENERIC_CPU_DEVICES is enabled, then cpu_dev_register_generic() will call arch_register_cpu() for each present CPU after this commit, rather than for each _possible_ CPU (which is the actual code change here.) > I'm not quite understand that, and how about when ACPI is enabled, which > function do this work? This is what happens later in the series. "drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden" adds a test for CONFIG_GENERIC_CPU_DEVICES, so this will only be used with architectures using GENERIC_CPU_DEVICES. Then in: "ACPI: processor: Register all CPUs from acpi_processor_get_info()" which is not part of this series, this adds a call to arch_register_cpu() in the ACPI code, and disables this path via a test for !acpi_disabled. Essentially, this path gets used to register the present CPUs when firmware (ACPI) isn't going to be registering the present CPUs. I've changed this to: "It makes very little sense to register all possible CPUs. Registering a CPU is what triggers the udev notifications allowing user-space to react to newly added CPUs. "To allow all five ACPI architectures to use GENERIC_CPU_DEVICES, change it to use for_each_present_cpu(). "Making the ACPI architectures use GENERIC_CPU_DEVICES is a pre-requisite step to centralise their register_cpu() logic, before moving it into the ACPI processor driver. When we add support for register CPUs from ACPI in a later patch, we will avoid registering CPUs in this path." which I hope makes it clearer. > > After this change, openrisc and hexagon systems that use the max_cpus > > command line argument would not see the other CPUs present in sysfs. > > This should not be a problem as these CPUs can't bre brought online as > ^ nit: can't be Thanks, I'll fix that. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Re: [RFC PATCH 2/2] docs: Update kernel-parameters.txt for signature verification enhancement
Hello Prarit, Il giorno mer 8 nov 2023 alle ore 16:33 Prarit Bhargava ha scritto: > > On 9/14/23 07:27, Alessandro Carminati (Red Hat) wrote: > > Update kernel-parameters.txt to reflect new deferred signature > > verification. > > Enhances boot speed by allowing unsigned modules in initrd after > > bootloader check. > > > > Signed-off-by: Alessandro Carminati (Red Hat) > > > > --- > > Documentation/admin-guide/kernel-parameters.txt | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > b/Documentation/admin-guide/kernel-parameters.txt > > index 0c38a8af95ce..beec86f0dd05 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -3410,6 +3410,15 @@ > > Note that if CONFIG_MODULE_SIG_FORCE is set, that > > is always true, so this option does nothing. > > > > + module_sig_check_wait= > > + This parameter enables delayed activation of module > > + signature checks, deferring the process until > > userspace > > + triggers it. Once activated, this setting becomes > > + permanent and cannot be reversed. This feature proves > > + valuable for incorporating unsigned modules within > > + initrd, especially after bootloader verification. > > + By employing this option, boot times can be quicker. > > + > > Please keep these in alphabetical order. > > Would making the kernel-parameters.txt warning a little bit more > informative be a good thing? This should only be used in environments > where some other signature verification method is employed. > > Also, for future reference, it would be good to have hard numbers to > show the boot time improvement in the changelog. I'll do the necessary adjustments in the v2, thank you for your feedback. > > P. > > > module_blacklist= [KNL] Do not load a comma-separated list of > > modules. Useful for debugging problem modules. > > >
Re: [PATCH RFC 08/22] drivers: base: Implement weak arch_unregister_cpu()
On 11/7/23 18:29, Russell King (Oracle) wrote:
From: James Morse
Add arch_unregister_cpu() to allow the ACPI machinery to call
unregister_cpu(). This is enough for arm64, riscv and loongarch, but
needs to be overridden by x86 and ia64 who need to do more work.
CC: Jean-Philippe Brucker
Signed-off-by: James Morse
Reviewed-by: Shaoqin Huang
---
Changes since v1:
* Added CONFIG_HOTPLUG_CPU ifdeffery around unregister_cpu
Changes since RFC v2:
* Move earlier in the series
---
drivers/base/cpu.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 579064fda97b..58bb86091b34 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -531,7 +531,14 @@ int __weak arch_register_cpu(int cpu)
{
return register_cpu(&per_cpu(cpu_devices, cpu), cpu);
}
-#endif
+
+#ifdef CONFIG_HOTPLUG_CPU
+void __weak arch_unregister_cpu(int num)
+{
+ unregister_cpu(&per_cpu(cpu_devices, num));
+}
+#endif /* CONFIG_HOTPLUG_CPU */
+#endif /* CONFIG_GENERIC_CPU_DEVICES */
static void __init cpu_dev_register_generic(void)
{
--
Shaoqin
Re: [RFC PATCH 0/2] Enhancing Boot Speed and Security with Delayed Module Signature Verification
gentle ping Il giorno gio 14 set 2023 alle ore 13:28 Alessandro Carminati (Red Hat) ha scritto: > > This patch sets up a new feature to the Linux kernel to have the ability, > while module signature checking is enabled, to delay the moment where > these signatures are effectively checked. The feature is structure into > two main key points, the feature can be enabled by a new command line > kernel argument, while in delay mode, the kernel waits until the > userspace communicates to start checking signature modules. > This operation can be done by writing a value in a securityfs file, > which works the same as /sys/kernel/security/lockdown. > > Patch 1/2: Modules: Introduce boot-time module signature flexibility > The first patch in this set fundamentally alters the kernel's behavior > at boot time by implementing a delayed module signature verification > mechanism. It introduces a new boot-time kernel argument that allows > users to request this delay. By doing so, we aim to capitalize on the > cryptographic checks already performed on the kernel and initrd images > during the secure boot process. As a result, we can significantly > improve the boot speed without compromising system security. > > Patch 2/2: docs: Update kernel-parameters.txt for signature verification > enhancement > The second patch is just to update the kernel parameters list > documentation. > > Background and Motivation > In certain contexts, boot speed becomes crucial. This patch follows the > recognition that security checks can at times be redundant. Therefore, > it proves valuable to skip those checks that have already been validated. > > In a typical Secure Boot startup with an initrd, the bootloader is > responsible for verifying artifacts before relinquishing control. In a > verified initrd image, it is reasonable to assume that its content is > also secure. Consequently, verifying module signatures may be deemed > unnecessary. > This patch introduces a feature to skip signature verification during > the initrd boot phase. > > Alessandro Carminati (Red Hat) (2): > Modules: Introduce boot-time module signature flexibility > docs: Update kernel-parameters.txt for signature verification > enhancement > > .../admin-guide/kernel-parameters.txt | 9 +++ > include/linux/module.h| 4 ++ > kernel/module/main.c | 14 +++-- > kernel/module/signing.c | 56 +++ > 4 files changed, 77 insertions(+), 6 deletions(-) > > -- > 2.34.1 >
Re: [PATCH RFC 06/22] drivers: base: Use present CPUs in GENERIC_CPU_DEVICES
On 11/9/23 18:29, Russell King (Oracle) wrote: On Thu, Nov 09, 2023 at 06:09:32PM +0800, Shaoqin Huang wrote: Hi Russell, On 11/7/23 18:29, Russell King (Oracle) wrote: From: James Morse Three of the five ACPI architectures create sysfs entries using register_cpu() for present CPUs, whereas arm64, riscv and all GENERIC_CPU_DEVICES do this for possible CPUs. Registering a CPU is what causes them to show up in sysfs. It makes very little sense to register all possible CPUs. Registering a CPU is what triggers the udev notifications allowing user-space to react to newly added CPUs. To allow all five ACPI architectures to use GENERIC_CPU_DEVICES, change it to use for_each_present_cpu(). Making the ACPI architectures use GENERIC_CPU_DEVICES is a pre-requisite step to centralise their cpu_register() logic, before moving it into the ACPI processor driver. When ACPI is disabled this work would be done by cpu_dev_register_generic(). What do you actually mean about when ACPI is disabled this work would be Firstly, please note that "you" is not appropriate here. This is James' commit message, not mine. Oh, Sorry for that. done by cpu_dev_register_generic()? Is the work means register the cpu? When ACPI is disabled _and_ CONFIG_GENERIC_CPU_DEVICES is enabled, then cpu_dev_register_generic() will call arch_register_cpu() for each present CPU after this commit, rather than for each _possible_ CPU (which is the actual code change here.) I'm not quite understand that, and how about when ACPI is enabled, which function do this work? This is what happens later in the series. "drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden" adds a test for CONFIG_GENERIC_CPU_DEVICES, so this will only be used with architectures using GENERIC_CPU_DEVICES. Then in: "ACPI: processor: Register all CPUs from acpi_processor_get_info()" which is not part of this series, this adds a call to arch_register_cpu() in the ACPI code, and disables this path via a test for !acpi_disabled. Essentially, this path gets used to register the present CPUs when firmware (ACPI) isn't going to be registering the present CPUs. I've changed this to: "It makes very little sense to register all possible CPUs. Registering a CPU is what triggers the udev notifications allowing user-space to react to newly added CPUs. "To allow all five ACPI architectures to use GENERIC_CPU_DEVICES, change it to use for_each_present_cpu(). "Making the ACPI architectures use GENERIC_CPU_DEVICES is a pre-requisite step to centralise their register_cpu() logic, before moving it into the ACPI processor driver. When we add support for register CPUs from ACPI in a later patch, we will avoid registering CPUs in this path." which I hope makes it clearer. Thanks for your great explanation. Change commit message to this makes me understand well. Thanks, Shaoqin After this change, openrisc and hexagon systems that use the max_cpus command line argument would not see the other CPUs present in sysfs. This should not be a problem as these CPUs can't bre brought online as ^ nit: can't be Thanks, I'll fix that.
Re: [PATCH RFC 09/22] drivers: base: add arch_cpu_is_hotpluggable()
On 11/7/23 18:30, Russell King (Oracle) wrote:
The differences between architecture specific implementations of
arch_register_cpu() are down to whether the CPU is hotpluggable or not.
Rather than overriding the weak version of arch_register_cpu(), provide
a function that can be used to provide this detail instead.
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
drivers/base/cpu.c | 11 ++-
include/linux/cpu.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 58bb86091b34..221ffbeb1c9b 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -527,9 +527,18 @@ EXPORT_SYMBOL_GPL(cpu_is_hotpluggable);
#ifdef CONFIG_GENERIC_CPU_DEVICES
DEFINE_PER_CPU(struct cpu, cpu_devices);
+bool __weak arch_cpu_is_hotpluggable(int cpu)
+{
+ return false;
+}
+
int __weak arch_register_cpu(int cpu)
{
- return register_cpu(&per_cpu(cpu_devices, cpu), cpu);
+ struct cpu *c = &per_cpu(cpu_devices, cpu);
+
+ c->hotpluggable = arch_cpu_is_hotpluggable(cpu);
+
+ return register_cpu(c, cpu);
}
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 1e982d63eae8..dcb89c987164 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -80,6 +80,7 @@ extern __printf(4, 5)
struct device *cpu_device_create(struct device *parent, void *drvdata,
const struct attribute_group **groups,
const char *fmt, ...);
+extern bool arch_cpu_is_hotpluggable(int cpu);
extern int arch_register_cpu(int cpu);
extern void arch_unregister_cpu(int cpu);
#ifdef CONFIG_HOTPLUG_CPU
--
Shaoqin
Re: [PATCH RFC 12/22] drivers: base: Print a warning instead of panic() when register_cpu() fails
On 11/7/23 18:30, Russell King (Oracle) wrote:
From: James Morse
loongarch, mips, parisc, riscv and sh all print a warning if
register_cpu() returns an error. Architectures that use
GENERIC_CPU_DEVICES call panic() instead.
Errors in this path indicate something is wrong with the firmware
description of the platform, but the kernel is able to keep running.
Downgrade this to a warning to make it easier to debug this issue.
This will allow architectures that switching over to GENERIC_CPU_DEVICES
to drop their warning, but keep the existing behaviour.
Signed-off-by: James Morse
Reviewed-by: Russell King (Oracle)
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
drivers/base/cpu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 221ffbeb1c9b..82b6a76125f5 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -551,14 +551,15 @@ void __weak arch_unregister_cpu(int num)
static void __init cpu_dev_register_generic(void)
{
- int i;
+ int i, ret;
if (!IS_ENABLED(CONFIG_GENERIC_CPU_DEVICES))
return;
for_each_present_cpu(i) {
- if (arch_register_cpu(i))
- panic("Failed to register CPU device");
+ ret = arch_register_cpu(i);
+ if (ret)
+ pr_warn("register_cpu %d failed (%d)\n", i, ret);
}
}
--
Shaoqin
Re: [PATCH RFC 14/22] arm64: convert to arch_cpu_is_hotpluggable()
On 11/7/23 18:30, Russell King (Oracle) wrote:
Convert arm64 to use the arch_cpu_is_hotpluggable() helper rather than
arch_register_cpu().
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
arch/arm64/kernel/setup.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 165bd2c0dd5a..42c690bb2d60 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -402,13 +402,9 @@ static inline bool cpu_can_disable(unsigned int cpu)
return false;
}
-int arch_register_cpu(int num)
+bool arch_cpu_is_hotpluggable(int num)
{
- struct cpu *cpu = &per_cpu(cpu_devices, num);
-
- cpu->hotpluggable = cpu_can_disable(num);
-
- return register_cpu(cpu, num);
+ return cpu_can_disable(num);
}
static void dump_kernel_offset(void)
--
Shaoqin
Re: [PATCH RFC 13/22] arm64: setup: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu()
On 11/7/23 18:30, Russell King (Oracle) wrote:
From: James Morse
To allow ACPI's _STA value to hide CPUs that are present, but not
available to online right now due to VMM or firmware policy, the
register_cpu() call needs to be made by the ACPI machinery when ACPI
is in use. This allows it to hide CPUs that are unavailable from sysfs.
Switching to GENERIC_CPU_DEVICES is an intermediate step to allow all
five ACPI architectures to be modified at once.
Switch over to GENERIC_CPU_DEVICES, and provide an arch_register_cpu()
that populates the hotpluggable flag. arch_register_cpu() is also the
interface the ACPI machinery expects.
The struct cpu in struct cpuinfo_arm64 is never used directly, remove
it to use the one GENERIC_CPU_DEVICES provides.
This changes the CPUs visible in sysfs from possible to present, but
on arm64 smp_prepare_cpus() ensures these are the same.
This patch also has the effect of moving the registration of CPUs from
subsys to driver core initialisation, prior to any initcalls running.
Signed-off-by: James Morse
Reviewed-by: Russell King (Oracle)
Signed-off-by: Russell King (Oracle)
Reviewed-by: Shaoqin Huang
---
Changes since RFC v2:
* Add note about initialisation order change.
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/cpu.h | 1 -
arch/arm64/kernel/setup.c| 13 -
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7b071a00425d..84bce830e365 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -132,6 +132,7 @@ config ARM64
select GENERIC_ARCH_TOPOLOGY
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_DEVICES
select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index f3034099fd95..b1e43f56ee46 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -38,7 +38,6 @@ struct cpuinfo_32bit {
};
struct cpuinfo_arm64 {
- struct cpu cpu;
struct kobject kobj;
u64 reg_ctr;
u64 reg_cntfrq;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 417a8a86b2db..165bd2c0dd5a 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -402,19 +402,14 @@ static inline bool cpu_can_disable(unsigned int cpu)
return false;
}
-static int __init topology_init(void)
+int arch_register_cpu(int num)
{
- int i;
+ struct cpu *cpu = &per_cpu(cpu_devices, num);
- for_each_possible_cpu(i) {
- struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
- cpu->hotpluggable = cpu_can_disable(i);
- register_cpu(cpu, i);
- }
+ cpu->hotpluggable = cpu_can_disable(num);
- return 0;
+ return register_cpu(cpu, num);
}
-subsys_initcall(topology_init);
static void dump_kernel_offset(void)
{
--
Shaoqin
