[RFC PATCH 2/2] Revert "cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()"

[salil . mehta]

From: Salil Mehta <salil.mehta@xxxxxxxxxx>

This reverts commit f9a82544c7174851f5c7524622f5966dcafd3a47.

That commit fixed a NULL kobject warning in cpuhp_smt_enable() by changing
arm64 so that Online-Capable but MADT-disabled CPUs are not initially in
cpu_present_mask, and by adding/removing them from that mask through the
ACPI map/unmap path.

The original arm64 virtual CPU hotplug model deliberately allowed CPUs to
be present but not enabled. cpu_enabled_mask was introduced to represent
exactly whether a present CPU may currently be brought online.

With the preceding change, cpuhp_smt_enable() now checks cpu_enabled()
before attempting _cpu_up(). This addresses the original warning at the
caller while preserving the present/enabled distinction and the arm64
virtual CPU hotplug model.

Restore the previous arm64 present-mask handling and documentation so that
all enumerated possible CPUs remain present while firmware availability is
represented by the enabled state.

This is posted as an RFC because there may be another reason why changing
the arm64 present-mask semantics is preferred over consuming the generic
enabled mask in cpuhp_smt_enable().

Signed-off-by: Salil Mehta <salil.mehta@xxxxxxxxxx>
---
 Documentation/arch/arm64/cpu-hotplug.rst | 28 ++++++++++--------------
 arch/arm64/kernel/acpi.c                 |  2 --
 arch/arm64/kernel/smp.c                  | 12 +---------
 3 files changed, 13 insertions(+), 29 deletions(-)

diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
index 7c3379b704aa..8fb438bf7781 100644
--- a/Documentation/arch/arm64/cpu-hotplug.rst
+++ b/Documentation/arch/arm64/cpu-hotplug.rst
@@ -47,12 +47,11 @@ ever have can be described at boot. There are no power-domain considerations
 as such devices are emulated.

 CPU Hotplug on virtual systems is supported. It is distinct from physical
-CPU Hotplug as all vCPU resources are statically described in the firmware
-configuration tables (e.g. MADT), meaning their maximum possible count is
-known at boot. However, vCPUs that are not enabled at boot are not marked
-as ``present`` by the kernel until they are hotplugged. An example is where
-a virtual machine boots with a single CPU, and additional CPUs are added
-once a cloud orchestrator deploys the workload.
+CPU Hotplug as all resources are described as ``present``, but CPUs may be
+marked as disabled by firmware. Only the CPU's online/offline behaviour is
+influenced by firmware. An example is where a virtual machine boots with a
+single CPU, and additional CPUs are added once a cloud orchestrator deploys
+the workload.

 For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.

@@ -61,19 +60,16 @@ brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
 ``DENIED``.

 The ACPI tables must describe all the resources of the virtual machine. CPUs
-that are hot-pluggable must have the ``online capable`` bit set and the
-``enabled`` bit cleared in the MADT GICC structures to indicate they can be
-enabled later. The boot CPU must be marked as ``enabled`` with its
-``online capable`` bit cleared. The 'always on' GICR structure must be used
-to describe the redistributors.
+that firmware wishes to disable either from boot (or later) should not be
+``enabled`` in the MADT GICC structures, but should have the ``online capable``
+bit set, to indicate they can be enabled later. The boot CPU must be marked as
+``enabled``.  The 'always on' GICR structure must be used to describe the
+redistributors.

 CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
 by the DSDT's Processor object's _STA method. On virtual systems the _STA method
-must always set the ``ACPI_STA_DEVICE_PRESENT`` bit, while toggling the
-``ACPI_STA_DEVICE_ENABLED`` bit to reflect its plug status. The kernel will
-then dynamically mark the vCPU as ``present`` within the OS when the
-``ACPI_STA_DEVICE_ENABLED`` bit becomes set during hot-add. Changes to the
-firmware policy can be notified to the OS via device-check or eject-request.
+must always report the CPU as ``present``. Changes to the firmware policy can
+be notified to the OS via device-check or eject-request.

 CPUs described as ``enabled`` in the static table, should not have their _STA
 modified dynamically by firmware. Soft-restart features such as kexec will
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 681aa2bbc399..5891f92c2035 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -448,14 +448,12 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
 		return *pcpu;
 	}

-	set_cpu_present(*pcpu, true);
 	return 0;
 }
 EXPORT_SYMBOL(acpi_map_cpu);

 int acpi_unmap_cpu(int cpu)
 {
-	set_cpu_present(cpu, false);
 	return 0;
 }
 EXPORT_SYMBOL(acpi_unmap_cpu);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a61dc3016a11..0c5292e4f4e0 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -558,11 +558,6 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
 }
 EXPORT_SYMBOL_GPL(acpi_cpu_get_madt_gicc);

-static bool acpi_cpu_is_present(int cpu)
-{
-	return acpi_cpu_get_madt_gicc(cpu)->flags & ACPI_MADT_ENABLED;
-}
-
 /*
  * acpi_map_gic_cpu_interface - parse processor MADT entry
  *
@@ -667,10 +662,6 @@ static void __init acpi_parse_and_init_cpus(void)
 		early_map_cpu_to_node(i, acpi_numa_get_nid(i));
 }
 #else
-static bool acpi_cpu_is_present(int cpu)
-{
-	return false;
-}
 #define acpi_parse_and_init_cpus(...)	do { } while (0)
 #endif

@@ -815,8 +806,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (err)
 			continue;

-		if (acpi_disabled || acpi_cpu_is_present(cpu))
-			set_cpu_present(cpu, true);
+		set_cpu_present(cpu, true);
 		numa_store_cpu_info(cpu);
 	}
 }
-- 
2.34.1