mbox series

[v10,00/19] ACPI/arm64: add support for virtual cpu hotplug

Message ID 20240529133446.28446-1-Jonathan.Cameron@huawei.com (mailing list archive)
Headers show
Series ACPI/arm64: add support for virtual cpu hotplug | expand

Message

Jonathan Cameron May 29, 2024, 1:34 p.m. UTC
v10:
- Make acpi_processor_set_per_cpu() return 0 / error rather than bool
  to simplify error handling at the call sites.
  (Thanks to both Rafael and Gavin who commented on this)
- Gather tags.
- Rebase on v6.10-rc1

The approach to the GICv3 changes stablized very late in the 6.10 cycle.
Subject to Marc taking a final look at those, I think we are now
in a good state wrt to those and the ACPI parts. The remaining code
that hasn't received review tags from the relevant maintainers
is the arm64 specific arch_register_cpu().  Given I think this will go
through the arm64 tree, hopefully they have just been waiting for
everything else to be ready.

It is only arch specific to the extent that Rafael suggested we limit
the potential impacts of the deferred calling of these functions
to be isolated to ARM64 for now.  This is done by having them return
-EPROBE_DEFER, on ACPI systems, until the ACPI interpreter is
available and can be used to query _STA.

Thanks to everyone who has been involved in development, testing and
review of this series - the complex tag chains reflect some of that.
Fingers crossed we are approaching the end of this particular saga.

Updated version of James' original introduction.

This series adds what looks like cpuhotplug support to arm64 for use in
virtual machines. It does this by moving the cpu_register() calls for
architectures that support ACPI into an arch specific call made from
the ACPI processor driver.
 
The kubernetes folk really want to be able to add CPUs to an existing VM,
in exactly the same way they do on x86. The use-case is pre-booting guests
with one CPU, then adding the number that were actually needed when the
workload is provisioned.

Wait? Doesn't arm64 support cpuhotplug already!?
In the arm world, cpuhotplug gets used to mean removing the power from a CPU.
The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug
has the additional step of physically removing the CPU, so that it isn't
present anymore.
 
Arm64 doesn't support this, and can't support it: CPUs are really a slice
of the SoC, and there is not enough information in the existing ACPI tables
to describe which bits of the slice also got removed. Without a reference
machine: adding this support to the spec is a wild goose chase.
 
Critically: everything described in the firmware tables must remain present.
 
For a virtual machine this is easy as all the other bits of 'virtual SoC'
are emulated, so they can (and do) remain present when a vCPU is 'removed'.

On a system that supports cpuhotplug the MADT has to describe every possible
CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before
the guest is started.
With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware
policy about which CPUs can be brought online.
 
This series adds support for virtual-cpuhotplug as exactly that: firmware
policy. This may even work on a physical machine too; for a guest the part of
firmware is played by the VMM. (typically Qemu).
 
PSCI support is modified to return 'DENIED' if the CPU can't be brought
online/enabled yet. The CPU object's _STA method's enabled bit is used to
indicate firmware's current disposition. If the CPU has its enabled bit clear,
it will not be registered with sysfs, and attempts to bring it online will
fail. The notifications that _STA has changed its value then work in the same
way as physical hotplug, and firmware can cause the CPU to be registered some
time later, allowing it to be brought online.
 
This creates something that looks like cpuhotplug to user-space and the
kernel beyond arm64 architecture specific code, as the sysfs
files appear and disappear, and the udev notifications look the same.
 
One notable difference is the CPU present mask, which is exposed via sysfs.
Because the CPUs remain present throughout, they can still be seen in that mask.
This value does get used by webbrowsers to estimate the number of CPUs
as the CPU online mask is constantly changed on mobile phones.
 
Linux is tolerant of PSCI returning errors, as its always been allowed to do
that. To avoid confusing OS that can't tolerate this, we needed an additional
bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which
appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it
has a different bit position in the GICC.
 
This code is unconditionally enabled for all ACPI architectures, though for
now only arm64 will have deferred the cpu_register() calls.

If folk want to play along at home, you'll need a copy of Qemu that supports this.
https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2

Replace your '-smp' argument with something like:
 | -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
 
 then feed the following to the Qemu montior;
 | (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
 | (qemu) device_del cpu1

James Morse (7):
  ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
  ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
  arm64: acpi: Move get_cpu_for_acpi_id() to a header
  irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
  irqchip/gic-v3: Add support for ACPI's disabled but 'online capable'
    CPUs
  arm64: document virtual CPU hotplug's expectations
  cpumask: Add enabled cpumask for present CPUs that can be brought
    online

Jean-Philippe Brucker (1):
  arm64: psci: Ignore DENIED CPUs

Jonathan Cameron (11):
  ACPI: processor: Simplify initial onlining to use same path for cold
    and hotplug
  cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
  ACPI: processor: Drop duplicated check on _STA (enabled + present)
  ACPI: processor: Return an error if acpi_processor_get_info() fails in
    processor_add()
  ACPI: processor: Fix memory leaks in error paths of processor_add()
  ACPI: processor: Move checks and availability of acpi_processor
    earlier
  ACPI: processor: Add acpi_get_processor_handle() helper
  ACPI: scan: switch to flags for acpi_scan_check_and_detach()
  arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
  arm64: arch_register_cpu() variant to check if an ACPI handle is now
    available.
  arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is
    enabled.

 .../ABI/testing/sysfs-devices-system-cpu      |   6 +
 Documentation/arch/arm64/cpu-hotplug.rst      |  79 ++++++++++
 Documentation/arch/arm64/index.rst            |   1 +
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/acpi.h                 |  12 ++
 arch/arm64/kernel/acpi.c                      |  22 +++
 arch/arm64/kernel/acpi_numa.c                 |  11 --
 arch/arm64/kernel/psci.c                      |   2 +-
 arch/arm64/kernel/smp.c                       |  59 +++++++-
 drivers/acpi/acpi_processor.c                 | 141 ++++++++++--------
 drivers/acpi/processor_core.c                 |   3 +-
 drivers/acpi/processor_driver.c               |  43 ++----
 drivers/acpi/scan.c                           |  47 +++++-
 drivers/base/cpu.c                            |  12 +-
 drivers/irqchip/irq-gic-v3.c                  |  57 +++++--
 include/acpi/acpi_bus.h                       |   1 +
 include/acpi/processor.h                      |   2 +-
 include/linux/acpi.h                          |  12 +-
 include/linux/cpumask.h                       |  25 ++++
 kernel/cpu.c                                  |   3 +
 20 files changed, 404 insertions(+), 135 deletions(-)
 create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst

Comments

Jonathan Cameron June 13, 2024, 10:25 a.m. UTC | #1
On Wed, 29 May 2024 14:34:27 +0100
Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:

> v10:
> - Make acpi_processor_set_per_cpu() return 0 / error rather than bool
>   to simplify error handling at the call sites.
>   (Thanks to both Rafael and Gavin who commented on this)
> - Gather tags.
> - Rebase on v6.10-rc1
> 
> The approach to the GICv3 changes stablized very late in the 6.10 cycle.
> Subject to Marc taking a final look at those, I think we are now
> in a good state wrt to those and the ACPI parts. The remaining code
> that hasn't received review tags from the relevant maintainers
> is the arm64 specific arch_register_cpu().  Given I think this will go
> through the arm64 tree, hopefully they have just been waiting for
> everything else to be ready.

Marc, Will, Catalin,

Any comments on this series?  We definitely want to finally land this
in 6.11!

Marc, in practice I think you already gave feedback on the the GICv3
changes in here as part of the discussions in the earlier version threads,
but if you have time for a final glance through it would be much appreciated.
Thanks for all your earlier help on this btw.

Will, Catalin.  There is an arch part, however it's just avoiding (for now)
earlier approach of making this common to all architectures after push back
from Rafael on the ACPI part, so more of an architecture specific
implementation choice than really anything to do with the architecture.
I'm currently assuming this will go through your tree.

Thanks,

Jonathan

> 
> It is only arch specific to the extent that Rafael suggested we limit
> the potential impacts of the deferred calling of these functions
> to be isolated to ARM64 for now.  This is done by having them return
> -EPROBE_DEFER, on ACPI systems, until the ACPI interpreter is
> available and can be used to query _STA.
> 
> Thanks to everyone who has been involved in development, testing and
> review of this series - the complex tag chains reflect some of that.
> Fingers crossed we are approaching the end of this particular saga.
> 
> Updated version of James' original introduction.
> 
> This series adds what looks like cpuhotplug support to arm64 for use in
> virtual machines. It does this by moving the cpu_register() calls for
> architectures that support ACPI into an arch specific call made from
> the ACPI processor driver.
>  
> The kubernetes folk really want to be able to add CPUs to an existing VM,
> in exactly the same way they do on x86. The use-case is pre-booting guests
> with one CPU, then adding the number that were actually needed when the
> workload is provisioned.
> 
> Wait? Doesn't arm64 support cpuhotplug already!?
> In the arm world, cpuhotplug gets used to mean removing the power from a CPU.
> The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug
> has the additional step of physically removing the CPU, so that it isn't
> present anymore.
>  
> Arm64 doesn't support this, and can't support it: CPUs are really a slice
> of the SoC, and there is not enough information in the existing ACPI tables
> to describe which bits of the slice also got removed. Without a reference
> machine: adding this support to the spec is a wild goose chase.
>  
> Critically: everything described in the firmware tables must remain present.
>  
> For a virtual machine this is easy as all the other bits of 'virtual SoC'
> are emulated, so they can (and do) remain present when a vCPU is 'removed'.
> 
> On a system that supports cpuhotplug the MADT has to describe every possible
> CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before
> the guest is started.
> With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware
> policy about which CPUs can be brought online.
>  
> This series adds support for virtual-cpuhotplug as exactly that: firmware
> policy. This may even work on a physical machine too; for a guest the part of
> firmware is played by the VMM. (typically Qemu).
>  
> PSCI support is modified to return 'DENIED' if the CPU can't be brought
> online/enabled yet. The CPU object's _STA method's enabled bit is used to
> indicate firmware's current disposition. If the CPU has its enabled bit clear,
> it will not be registered with sysfs, and attempts to bring it online will
> fail. The notifications that _STA has changed its value then work in the same
> way as physical hotplug, and firmware can cause the CPU to be registered some
> time later, allowing it to be brought online.
>  
> This creates something that looks like cpuhotplug to user-space and the
> kernel beyond arm64 architecture specific code, as the sysfs
> files appear and disappear, and the udev notifications look the same.
>  
> One notable difference is the CPU present mask, which is exposed via sysfs.
> Because the CPUs remain present throughout, they can still be seen in that mask.
> This value does get used by webbrowsers to estimate the number of CPUs
> as the CPU online mask is constantly changed on mobile phones.
>  
> Linux is tolerant of PSCI returning errors, as its always been allowed to do
> that. To avoid confusing OS that can't tolerate this, we needed an additional
> bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which
> appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it
> has a different bit position in the GICC.
>  
> This code is unconditionally enabled for all ACPI architectures, though for
> now only arm64 will have deferred the cpu_register() calls.
> 
> If folk want to play along at home, you'll need a copy of Qemu that supports this.
> https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2
> 
> Replace your '-smp' argument with something like:
>  | -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
>  
>  then feed the following to the Qemu montior;
>  | (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
>  | (qemu) device_del cpu1
> 
> James Morse (7):
>   ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
>   ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
>   arm64: acpi: Move get_cpu_for_acpi_id() to a header
>   irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
>   irqchip/gic-v3: Add support for ACPI's disabled but 'online capable'
>     CPUs
>   arm64: document virtual CPU hotplug's expectations
>   cpumask: Add enabled cpumask for present CPUs that can be brought
>     online
> 
> Jean-Philippe Brucker (1):
>   arm64: psci: Ignore DENIED CPUs
> 
> Jonathan Cameron (11):
>   ACPI: processor: Simplify initial onlining to use same path for cold
>     and hotplug
>   cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
>   ACPI: processor: Drop duplicated check on _STA (enabled + present)
>   ACPI: processor: Return an error if acpi_processor_get_info() fails in
>     processor_add()
>   ACPI: processor: Fix memory leaks in error paths of processor_add()
>   ACPI: processor: Move checks and availability of acpi_processor
>     earlier
>   ACPI: processor: Add acpi_get_processor_handle() helper
>   ACPI: scan: switch to flags for acpi_scan_check_and_detach()
>   arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
>   arm64: arch_register_cpu() variant to check if an ACPI handle is now
>     available.
>   arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is
>     enabled.
> 
>  .../ABI/testing/sysfs-devices-system-cpu      |   6 +
>  Documentation/arch/arm64/cpu-hotplug.rst      |  79 ++++++++++
>  Documentation/arch/arm64/index.rst            |   1 +
>  arch/arm64/Kconfig                            |   1 +
>  arch/arm64/include/asm/acpi.h                 |  12 ++
>  arch/arm64/kernel/acpi.c                      |  22 +++
>  arch/arm64/kernel/acpi_numa.c                 |  11 --
>  arch/arm64/kernel/psci.c                      |   2 +-
>  arch/arm64/kernel/smp.c                       |  59 +++++++-
>  drivers/acpi/acpi_processor.c                 | 141 ++++++++++--------
>  drivers/acpi/processor_core.c                 |   3 +-
>  drivers/acpi/processor_driver.c               |  43 ++----
>  drivers/acpi/scan.c                           |  47 +++++-
>  drivers/base/cpu.c                            |  12 +-
>  drivers/irqchip/irq-gic-v3.c                  |  57 +++++--
>  include/acpi/acpi_bus.h                       |   1 +
>  include/acpi/processor.h                      |   2 +-
>  include/linux/acpi.h                          |  12 +-
>  include/linux/cpumask.h                       |  25 ++++
>  kernel/cpu.c                                  |   3 +
>  20 files changed, 404 insertions(+), 135 deletions(-)
>  create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst
>
Marc Zyngier June 19, 2024, 12:11 p.m. UTC | #2
On Thu, 13 Jun 2024 11:25:27 +0100,
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> 
> On Wed, 29 May 2024 14:34:27 +0100
> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> 
> > v10:
> > - Make acpi_processor_set_per_cpu() return 0 / error rather than bool
> >   to simplify error handling at the call sites.
> >   (Thanks to both Rafael and Gavin who commented on this)
> > - Gather tags.
> > - Rebase on v6.10-rc1
> > 
> > The approach to the GICv3 changes stablized very late in the 6.10 cycle.
> > Subject to Marc taking a final look at those, I think we are now
> > in a good state wrt to those and the ACPI parts. The remaining code
> > that hasn't received review tags from the relevant maintainers
> > is the arm64 specific arch_register_cpu().  Given I think this will go
> > through the arm64 tree, hopefully they have just been waiting for
> > everything else to be ready.
> 
> Marc, Will, Catalin,
> 
> Any comments on this series?  We definitely want to finally land this
> in 6.11!
> 
> Marc, in practice I think you already gave feedback on the the GICv3
> changes in here as part of the discussions in the earlier version threads,
> but if you have time for a final glance through it would be much appreciated.
> Thanks for all your earlier help on this btw.

I've had a quick look and the GICv3 parts look OK to me (you should
now have by tags for both patches).

Thanks,

	M.
Jonathan Cameron June 28, 2024, 2:49 p.m. UTC | #3
On Wed, 19 Jun 2024 13:11:47 +0100
Marc Zyngier <maz@kernel.org> wrote:

> On Thu, 13 Jun 2024 11:25:27 +0100,
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> > 
> > On Wed, 29 May 2024 14:34:27 +0100
> > Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> >   
> > > v10:
> > > - Make acpi_processor_set_per_cpu() return 0 / error rather than bool
> > >   to simplify error handling at the call sites.
> > >   (Thanks to both Rafael and Gavin who commented on this)
> > > - Gather tags.
> > > - Rebase on v6.10-rc1
> > > 
> > > The approach to the GICv3 changes stablized very late in the 6.10 cycle.
> > > Subject to Marc taking a final look at those, I think we are now
> > > in a good state wrt to those and the ACPI parts. The remaining code
> > > that hasn't received review tags from the relevant maintainers
> > > is the arm64 specific arch_register_cpu().  Given I think this will go
> > > through the arm64 tree, hopefully they have just been waiting for
> > > everything else to be ready.  
> > 
> > Marc, Will, Catalin,
> > 
> > Any comments on this series?  We definitely want to finally land this
> > in 6.11!
> > 
> > Marc, in practice I think you already gave feedback on the the GICv3
> > changes in here as part of the discussions in the earlier version threads,
> > but if you have time for a final glance through it would be much appreciated.
> > Thanks for all your earlier help on this btw.  
> 
> I've had a quick look and the GICv3 parts look OK to me (you should
> now have by tags for both patches).
> 
> Thanks,
> 
> 	M.

Thanks again for your help with this one Marc.

Will, Catalin? We are nearly at RC6 and this series has been unchanged all cycle.
Great to hear your opinions on this.  My assumption is that it will go through
your tree if you are happy with it.

Thanks,

Jonathan
Catalin Marinas June 28, 2024, 5:56 p.m. UTC | #4
On Wed, 29 May 2024 14:34:27 +0100, Jonathan Cameron wrote:
> v10:
> - Make acpi_processor_set_per_cpu() return 0 / error rather than bool
>   to simplify error handling at the call sites.
>   (Thanks to both Rafael and Gavin who commented on this)
> - Gather tags.
> - Rebase on v6.10-rc1
> 
> [...]

Applied to arm64 (for-next/vcpu-hotplug), thanks! If nothing falls
apart, it should end up in mainline for 6.11.

Thomas, the GICv3 patches have been acked by Marc but they are missing
your ack. If you want it added, I can refresh the series in the next day
or so, otherwise the branch should remain stable. Thanks.

[01/19] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug
        https://git.kernel.org/arm64/c/c1385c1f0ba3
[02/19] cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
        https://git.kernel.org/arm64/c/d830ef3ac569
[03/19] ACPI: processor: Drop duplicated check on _STA (enabled + present)
        https://git.kernel.org/arm64/c/157080f03c7a
[04/19] ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add()
        https://git.kernel.org/arm64/c/fadf231f0a06
[05/19] ACPI: processor: Fix memory leaks in error paths of processor_add()
        https://git.kernel.org/arm64/c/47ec9b417ed9
[06/19] ACPI: processor: Move checks and availability of acpi_processor earlier
        https://git.kernel.org/arm64/c/cd9239660b8c
[07/19] ACPI: processor: Add acpi_get_processor_handle() helper
        https://git.kernel.org/arm64/c/36b921637e90
[08/19] ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
        https://git.kernel.org/arm64/c/b398a91decd9
[09/19] ACPI: scan: switch to flags for acpi_scan_check_and_detach()
        https://git.kernel.org/arm64/c/1859a671bdb9
[10/19] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
        https://git.kernel.org/arm64/c/3b9d0a78aeda
[11/19] arm64: acpi: Move get_cpu_for_acpi_id() to a header
        https://git.kernel.org/arm64/c/8d34b6f17b9a
[12/19] arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
        https://git.kernel.org/arm64/c/2488444274c7
[13/19] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
        https://git.kernel.org/arm64/c/fa2dabe57220
[14/19] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs
        https://git.kernel.org/arm64/c/d633da5d3ab1
[15/19] arm64: psci: Ignore DENIED CPUs
        https://git.kernel.org/arm64/c/643e12da4a49
[16/19] arm64: arch_register_cpu() variant to check if an ACPI handle is now available.
        https://git.kernel.org/arm64/c/eba4675008a6
[17/19] arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled.
        https://git.kernel.org/arm64/c/9d0873892f4d
[18/19] arm64: document virtual CPU hotplug's expectations
        https://git.kernel.org/arm64/c/828ce929d1c3
[19/19] cpumask: Add enabled cpumask for present CPUs that can be brought online
        https://git.kernel.org/arm64/c/4e1a7df45480