All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Cc: <linux-pm@vger.kernel.org>, <loongarch@lists.linux.dev>,
	<linux-acpi@vger.kernel.org>, <linux-arch@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's expectations
Date: Fri, 15 Dec 2023 17:04:28 +0000	[thread overview]
Message-ID: <20231215170428.00000d81@Huawei.com> (raw)
In-Reply-To: <E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>

On Wed, 13 Dec 2023 12:50:49 +0000
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:

> From: James Morse <james.morse@arm.com>
> 
> Add a description of physical and virtual CPU hotplug, explain the
> differences and elaborate on what is required in ACPI for a working
> virtual hotplug system.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  Outstanding comment:
>   https://lore.kernel.org/r/20230914174137.00000a62@Huawei.com

Hmm. This one is the comment that if we allow for a legacy unware guest, we
have no way of indicating that CPUS that were enabled at boot can ever be removed.

Effectively that means that without the cloud being aware of the VM capabilities
before it is booted (and can maybe use the proposed OSC) there is no way of knowing
if a CPU can be removed.  Sounds profitable :)

I'm fine with that.  So as long a people grasp the concern and we make sure that
the QEMU side doesn't change it's legacy behavior (I think we are fine in Salil's
latest set).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


Jonathan


> ---
>  Documentation/arch/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++++++++
>  Documentation/arch/arm64/index.rst       |  1 +
>  2 files changed, 80 insertions(+)
>  create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst
> 
> diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
> new file mode 100644
> index 000000000000..76ba8d932c72
> --- /dev/null
> +++ b/Documentation/arch/arm64/cpu-hotplug.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. _cpuhp_index:
> +
> +====================
> +CPU Hotplug and ACPI
> +====================
> +
> +CPU hotplug in the arm64 world is commonly used to describe the kernel taking
> +CPUs online/offline using PSCI. This document is about ACPI firmware allowing
> +CPUs that were not available during boot to be added to the system later.
> +
> +``possible`` and ``present`` refer to the state of the CPU as seen by linux.
> +
> +
> +CPU Hotplug on physical systems - CPUs not present at boot
> +----------------------------------------------------------
> +
> +Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
> +being ``present``. An example would be a dual socket machine, where the package
> +in one of the sockets can be replaced while the system is running.
> +
> +This is not supported.
> +
> +In the arm64 world CPUs are not a single device but a slice of the system.
> +There are no systems that support the physical addition (or removal) of CPUs
> +while the system is running, and ACPI is not able to sufficiently describe
> +them.
> +
> +e.g. New CPUs come with new caches, but the platform's cache toplogy is
> +described in a static table, the PPTT. How caches are shared between CPUs is
> +not discoverable, and must be described by firmware.
> +
> +e.g. The GIC redistributor for each CPU must be accessed by the driver during
> +boot to discover the system wide supported features. ACPI's MADT GICC
> +structures can describe a redistributor associated with a disabled CPU, but
> +can't describe whether the redistributor is accessible, only that it is not
> +'always on'.
> +
> +arm64's ACPI tables assume that everything described is ``present``.
> +
> +
> +CPU Hotplug on virtual systems - CPUs not enabled at boot
> +---------------------------------------------------------
> +
> +Virtual systems have the advantage that all the properties the system will
> +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 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.
> +
> +Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
> +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 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 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
> +re-read the static properties of the system from these static tables, and
> +may malfunction if these no longer describe the running system. Linux will
> +re-discover the dynamic properties of the system from the _STA method later
> +during boot.
> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
> index d08e924204bf..78544de0a8a9 100644
> --- a/Documentation/arch/arm64/index.rst
> +++ b/Documentation/arch/arm64/index.rst
> @@ -13,6 +13,7 @@ ARM64 Architecture
>      asymmetric-32bit
>      booting
>      cpu-feature-registers
> +    cpu-hotplug
>      elf_hwcaps
>      hugetlbpage
>      kdump


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Cc: <linux-pm@vger.kernel.org>, <loongarch@lists.linux.dev>,
	<linux-acpi@vger.kernel.org>, <linux-arch@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's expectations
Date: Fri, 15 Dec 2023 17:04:28 +0000	[thread overview]
Message-ID: <20231215170428.00000d81@Huawei.com> (raw)
In-Reply-To: <E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>

On Wed, 13 Dec 2023 12:50:49 +0000
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:

> From: James Morse <james.morse@arm.com>
> 
> Add a description of physical and virtual CPU hotplug, explain the
> differences and elaborate on what is required in ACPI for a working
> virtual hotplug system.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  Outstanding comment:
>   https://lore.kernel.org/r/20230914174137.00000a62@Huawei.com

Hmm. This one is the comment that if we allow for a legacy unware guest, we
have no way of indicating that CPUS that were enabled at boot can ever be removed.

Effectively that means that without the cloud being aware of the VM capabilities
before it is booted (and can maybe use the proposed OSC) there is no way of knowing
if a CPU can be removed.  Sounds profitable :)

I'm fine with that.  So as long a people grasp the concern and we make sure that
the QEMU side doesn't change it's legacy behavior (I think we are fine in Salil's
latest set).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


Jonathan


> ---
>  Documentation/arch/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++++++++
>  Documentation/arch/arm64/index.rst       |  1 +
>  2 files changed, 80 insertions(+)
>  create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst
> 
> diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
> new file mode 100644
> index 000000000000..76ba8d932c72
> --- /dev/null
> +++ b/Documentation/arch/arm64/cpu-hotplug.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. _cpuhp_index:
> +
> +====================
> +CPU Hotplug and ACPI
> +====================
> +
> +CPU hotplug in the arm64 world is commonly used to describe the kernel taking
> +CPUs online/offline using PSCI. This document is about ACPI firmware allowing
> +CPUs that were not available during boot to be added to the system later.
> +
> +``possible`` and ``present`` refer to the state of the CPU as seen by linux.
> +
> +
> +CPU Hotplug on physical systems - CPUs not present at boot
> +----------------------------------------------------------
> +
> +Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
> +being ``present``. An example would be a dual socket machine, where the package
> +in one of the sockets can be replaced while the system is running.
> +
> +This is not supported.
> +
> +In the arm64 world CPUs are not a single device but a slice of the system.
> +There are no systems that support the physical addition (or removal) of CPUs
> +while the system is running, and ACPI is not able to sufficiently describe
> +them.
> +
> +e.g. New CPUs come with new caches, but the platform's cache toplogy is
> +described in a static table, the PPTT. How caches are shared between CPUs is
> +not discoverable, and must be described by firmware.
> +
> +e.g. The GIC redistributor for each CPU must be accessed by the driver during
> +boot to discover the system wide supported features. ACPI's MADT GICC
> +structures can describe a redistributor associated with a disabled CPU, but
> +can't describe whether the redistributor is accessible, only that it is not
> +'always on'.
> +
> +arm64's ACPI tables assume that everything described is ``present``.
> +
> +
> +CPU Hotplug on virtual systems - CPUs not enabled at boot
> +---------------------------------------------------------
> +
> +Virtual systems have the advantage that all the properties the system will
> +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 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.
> +
> +Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
> +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 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 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
> +re-read the static properties of the system from these static tables, and
> +may malfunction if these no longer describe the running system. Linux will
> +re-discover the dynamic properties of the system from the _STA method later
> +during boot.
> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
> index d08e924204bf..78544de0a8a9 100644
> --- a/Documentation/arch/arm64/index.rst
> +++ b/Documentation/arch/arm64/index.rst
> @@ -13,6 +13,7 @@ ARM64 Architecture
>      asymmetric-32bit
>      booting
>      cpu-feature-registers
> +    cpu-hotplug
>      elf_hwcaps
>      hugetlbpage
>      kdump


WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Cc: <linux-pm@vger.kernel.org>, <loongarch@lists.linux.dev>,
	<linux-acpi@vger.kernel.org>, <linux-arch@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-riscv@lists.infradead.org>, <kvmarm@lists.linux.dev>,
	<x86@kernel.org>, <acpica-devel@lists.linuxfoundation.org>,
	<linux-csky@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-ia64@vger.kernel.org>, <linux-parisc@vger.kernel.org>,
	Salil Mehta <salil.mehta@huawei.com>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	<jianyong.wu@arm.com>, <justin.he@arm.com>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's expectations
Date: Fri, 15 Dec 2023 17:04:28 +0000	[thread overview]
Message-ID: <20231215170428.00000d81@Huawei.com> (raw)
In-Reply-To: <E1rDOhN-00DvlU-2e@rmk-PC.armlinux.org.uk>

On Wed, 13 Dec 2023 12:50:49 +0000
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> wrote:

> From: James Morse <james.morse@arm.com>
> 
> Add a description of physical and virtual CPU hotplug, explain the
> differences and elaborate on what is required in ACPI for a working
> virtual hotplug system.
> 
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  Outstanding comment:
>   https://lore.kernel.org/r/20230914174137.00000a62@Huawei.com

Hmm. This one is the comment that if we allow for a legacy unware guest, we
have no way of indicating that CPUS that were enabled at boot can ever be removed.

Effectively that means that without the cloud being aware of the VM capabilities
before it is booted (and can maybe use the proposed OSC) there is no way of knowing
if a CPU can be removed.  Sounds profitable :)

I'm fine with that.  So as long a people grasp the concern and we make sure that
the QEMU side doesn't change it's legacy behavior (I think we are fine in Salil's
latest set).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>


Jonathan


> ---
>  Documentation/arch/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++++++++
>  Documentation/arch/arm64/index.rst       |  1 +
>  2 files changed, 80 insertions(+)
>  create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst
> 
> diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
> new file mode 100644
> index 000000000000..76ba8d932c72
> --- /dev/null
> +++ b/Documentation/arch/arm64/cpu-hotplug.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. _cpuhp_index:
> +
> +====================
> +CPU Hotplug and ACPI
> +====================
> +
> +CPU hotplug in the arm64 world is commonly used to describe the kernel taking
> +CPUs online/offline using PSCI. This document is about ACPI firmware allowing
> +CPUs that were not available during boot to be added to the system later.
> +
> +``possible`` and ``present`` refer to the state of the CPU as seen by linux.
> +
> +
> +CPU Hotplug on physical systems - CPUs not present at boot
> +----------------------------------------------------------
> +
> +Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
> +being ``present``. An example would be a dual socket machine, where the package
> +in one of the sockets can be replaced while the system is running.
> +
> +This is not supported.
> +
> +In the arm64 world CPUs are not a single device but a slice of the system.
> +There are no systems that support the physical addition (or removal) of CPUs
> +while the system is running, and ACPI is not able to sufficiently describe
> +them.
> +
> +e.g. New CPUs come with new caches, but the platform's cache toplogy is
> +described in a static table, the PPTT. How caches are shared between CPUs is
> +not discoverable, and must be described by firmware.
> +
> +e.g. The GIC redistributor for each CPU must be accessed by the driver during
> +boot to discover the system wide supported features. ACPI's MADT GICC
> +structures can describe a redistributor associated with a disabled CPU, but
> +can't describe whether the redistributor is accessible, only that it is not
> +'always on'.
> +
> +arm64's ACPI tables assume that everything described is ``present``.
> +
> +
> +CPU Hotplug on virtual systems - CPUs not enabled at boot
> +---------------------------------------------------------
> +
> +Virtual systems have the advantage that all the properties the system will
> +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 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.
> +
> +Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
> +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 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 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
> +re-read the static properties of the system from these static tables, and
> +may malfunction if these no longer describe the running system. Linux will
> +re-discover the dynamic properties of the system from the _STA method later
> +during boot.
> diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
> index d08e924204bf..78544de0a8a9 100644
> --- a/Documentation/arch/arm64/index.rst
> +++ b/Documentation/arch/arm64/index.rst
> @@ -13,6 +13,7 @@ ARM64 Architecture
>      asymmetric-32bit
>      booting
>      cpu-feature-registers
> +    cpu-hotplug
>      elf_hwcaps
>      hugetlbpage
>      kdump


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-15 17:04 UTC|newest]

Thread overview: 363+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 12:47 [RFC PATCH v3 00/21] ACPI/arm64: add support for virtual cpu hotplug Russell King (Oracle)
2023-12-13 12:47 ` Russell King (Oracle)
2023-12-13 12:47 ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 01/21] ACPI: Only enumerate enabled (or functional) devices Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:32   ` Jonathan Cameron
2023-12-14 17:32     ` Jonathan Cameron
2023-12-14 17:32     ` Jonathan Cameron
2023-12-14 17:47     ` Rafael J. Wysocki
2023-12-14 17:47       ` Rafael J. Wysocki
2023-12-14 17:47       ` Rafael J. Wysocki
2023-12-14 18:10       ` Russell King (Oracle)
2023-12-14 18:10         ` Russell King (Oracle)
2023-12-14 18:10         ` Russell King (Oracle)
2023-12-14 18:16         ` Rafael J. Wysocki
2023-12-14 18:16           ` Rafael J. Wysocki
2023-12-14 18:16           ` Rafael J. Wysocki
2023-12-14 18:37           ` Rafael J. Wysocki
2023-12-14 18:37             ` Rafael J. Wysocki
2023-12-14 18:37             ` Rafael J. Wysocki
2023-12-15 15:31             ` Russell King (Oracle)
2023-12-15 15:31               ` Russell King (Oracle)
2023-12-15 15:31               ` Russell King (Oracle)
2023-12-15 16:15               ` Jonathan Cameron
2023-12-15 16:15                 ` Jonathan Cameron
2023-12-15 16:15                 ` Jonathan Cameron
2023-12-15 19:47                 ` Rafael J. Wysocki
2023-12-15 19:47                   ` Rafael J. Wysocki
2023-12-15 19:47                   ` Rafael J. Wysocki
2024-01-02 14:39                   ` Jonathan Cameron
2024-01-02 14:39                     ` Jonathan Cameron
2024-01-02 14:39                     ` Jonathan Cameron
2024-01-11 10:19                     ` Jonathan Cameron
2024-01-11 10:19                       ` Jonathan Cameron
2024-01-11 10:19                       ` Jonathan Cameron
2024-01-11 10:26                       ` Russell King (Oracle)
2024-01-11 10:26                         ` Russell King (Oracle)
2024-01-11 10:26                         ` Russell King (Oracle)
2024-01-12 11:52                         ` Jonathan Cameron
2024-01-12 11:52                           ` Jonathan Cameron
2024-01-12 11:52                           ` Jonathan Cameron
2024-01-29 14:55                           ` Russell King (Oracle)
2024-01-29 14:55                             ` Russell King (Oracle)
2024-01-29 14:55                             ` Russell King (Oracle)
2024-01-29 15:05                             ` Rafael J. Wysocki
2024-01-29 15:05                               ` Rafael J. Wysocki
2024-01-29 15:05                               ` Rafael J. Wysocki
2024-01-29 15:16                               ` Russell King (Oracle)
2024-01-29 15:16                                 ` Russell King (Oracle)
2024-01-29 15:16                                 ` Russell King (Oracle)
2024-01-29 15:34                                 ` Rafael J. Wysocki
2024-01-29 15:34                                   ` Rafael J. Wysocki
2024-01-29 15:34                                   ` Rafael J. Wysocki
2024-01-22  7:31                         ` Gavin Shan
2024-01-22  7:31                           ` Gavin Shan
2024-01-22  7:31                           ` Gavin Shan
2023-12-14 17:55     ` Russell King (Oracle)
2023-12-14 17:55       ` Russell King (Oracle)
2023-12-14 17:55       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 02/21] ACPI: processor: Add support for processors described as container packages Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:36   ` Jonathan Cameron
2023-12-14 17:36     ` Jonathan Cameron
2023-12-14 17:36     ` Jonathan Cameron
2023-12-14 17:57     ` Russell King (Oracle)
2023-12-14 17:57       ` Russell King (Oracle)
2023-12-14 17:57       ` Russell King (Oracle)
2023-12-18 20:17   ` Rafael J. Wysocki
2023-12-18 20:17     ` Rafael J. Wysocki
2023-12-18 20:17     ` Rafael J. Wysocki
2024-01-09 15:49     ` Russell King (Oracle)
2024-01-09 15:49       ` Russell King (Oracle)
2024-01-09 15:49       ` Russell King (Oracle)
2024-01-09 16:05       ` Rafael J. Wysocki
2024-01-09 16:05         ` Rafael J. Wysocki
2024-01-09 16:05         ` Rafael J. Wysocki
2024-01-09 16:13         ` Russell King (Oracle)
2024-01-09 16:13           ` Russell King (Oracle)
2024-01-09 16:13           ` Russell King (Oracle)
2024-01-11 16:17           ` Jonathan Cameron
2024-01-11 16:17             ` Jonathan Cameron
2024-01-11 16:17             ` Jonathan Cameron
2024-01-11 17:59     ` Jonathan Cameron
2024-01-11 17:59       ` Jonathan Cameron
2024-01-11 17:59       ` Jonathan Cameron
2024-01-11 18:46       ` Russell King (Oracle)
2024-01-11 18:46         ` Russell King (Oracle)
2024-01-11 18:46         ` Russell King (Oracle)
2024-01-12  9:25         ` Jonathan Cameron
2024-01-12  9:25           ` Jonathan Cameron
2024-01-12  9:25           ` Jonathan Cameron
2024-01-12 15:01           ` Rafael J. Wysocki
2024-01-12 15:01             ` Rafael J. Wysocki
2024-01-12 15:01             ` Rafael J. Wysocki
2024-01-12 15:03             ` Jonathan Cameron
2024-01-12 15:03               ` Jonathan Cameron
2024-01-12 15:03               ` Jonathan Cameron
2024-01-15 10:47             ` Russell King (Oracle)
2024-01-15 10:47               ` Russell King (Oracle)
2024-01-15 10:47               ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 03/21] ACPI: processor: Register CPUs that are online, but not described in the DSDT Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-18 20:22   ` Rafael J. Wysocki
2023-12-18 20:22     ` Rafael J. Wysocki
2023-12-18 20:22     ` Rafael J. Wysocki
2024-01-15 11:06     ` Russell King (Oracle)
2024-01-15 11:06       ` Russell King (Oracle)
2024-01-15 11:06       ` Russell King (Oracle)
2024-01-22 16:02       ` Jonathan Cameron
2024-01-22 16:02         ` Jonathan Cameron
2024-01-22 16:02         ` Jonathan Cameron
2024-01-22 16:22         ` Rafael J. Wysocki
2024-01-22 16:22           ` Rafael J. Wysocki
2024-01-22 16:22           ` Rafael J. Wysocki
2024-01-22 17:30           ` Russell King (Oracle)
2024-01-22 17:30             ` Russell King (Oracle)
2024-01-22 17:30             ` Russell King (Oracle)
2024-01-23  9:27             ` Jonathan Cameron
2024-01-23  9:27               ` Jonathan Cameron
2024-01-23  9:27               ` Jonathan Cameron
2024-01-25 13:56               ` Miguel Luis
2024-01-25 13:56                 ` Miguel Luis
2024-01-25 13:56                 ` Miguel Luis
2024-01-25 14:42                 ` Rafael J. Wysocki
2024-01-25 14:42                   ` Rafael J. Wysocki
2024-01-25 14:42                   ` Rafael J. Wysocki
2024-01-29 13:03               ` Jonathan Cameron
2024-01-29 13:03                 ` Jonathan Cameron
2024-01-29 13:03                 ` Jonathan Cameron
2024-01-29 15:32                 ` Russell King (Oracle)
2024-01-29 15:32                   ` Russell King (Oracle)
2024-01-29 15:32                   ` Russell King (Oracle)
2024-01-22 17:27         ` Russell King (Oracle)
2024-01-22 17:27           ` Russell King (Oracle)
2024-01-22 17:27           ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 04/21] ACPI: processor: Register all CPUs from acpi_processor_get_info() Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:38   ` Jonathan Cameron
2023-12-14 17:38     ` Jonathan Cameron
2023-12-14 17:38     ` Jonathan Cameron
2023-12-18 20:30   ` Rafael J. Wysocki
2023-12-18 20:30     ` Rafael J. Wysocki
2023-12-18 20:30     ` Rafael J. Wysocki
2024-01-22 17:44     ` Jonathan Cameron
2024-01-22 17:44       ` Jonathan Cameron
2024-01-22 17:44       ` Jonathan Cameron
2024-01-22 18:03       ` Rafael J. Wysocki
2024-01-22 18:03         ` Rafael J. Wysocki
2024-01-22 18:03         ` Rafael J. Wysocki
2024-01-22 21:56     ` Russell King (Oracle)
2024-01-22 21:56       ` Russell King (Oracle)
2024-01-22 21:56       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 05/21] ACPI: Rename ACPI_HOTPLUG_CPU to include 'present' Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:41   ` Jonathan Cameron
2023-12-14 17:41     ` Jonathan Cameron
2023-12-14 17:41     ` Jonathan Cameron
2023-12-14 18:00     ` Russell King (Oracle)
2023-12-14 18:00       ` Russell King (Oracle)
2023-12-14 18:00       ` Russell King (Oracle)
2023-12-18 20:35   ` Rafael J. Wysocki
2023-12-18 20:35     ` Rafael J. Wysocki
2023-12-18 20:35     ` Rafael J. Wysocki
2024-01-22 18:00     ` Jonathan Cameron
2024-01-22 18:00       ` Jonathan Cameron
2024-01-22 18:00       ` Jonathan Cameron
2024-01-23 13:28       ` Russell King (Oracle)
2024-01-23 13:28         ` Russell King (Oracle)
2024-01-23 13:28         ` Russell King (Oracle)
2024-01-23 16:15         ` Rafael J. Wysocki
2024-01-23 16:15           ` Rafael J. Wysocki
2024-01-23 16:15           ` Rafael J. Wysocki
2024-01-23 16:36           ` Russell King (Oracle)
2024-01-23 16:36             ` Russell King (Oracle)
2024-01-23 16:36             ` Russell King (Oracle)
2024-01-23 17:43             ` Rafael J. Wysocki
2024-01-23 17:43               ` Rafael J. Wysocki
2024-01-23 17:43               ` Rafael J. Wysocki
2024-01-23 18:19               ` Russell King (Oracle)
2024-01-23 18:19                 ` Russell King (Oracle)
2024-01-23 18:19                 ` Russell King (Oracle)
2024-01-23 18:26                 ` Rafael J. Wysocki
2024-01-23 18:26                   ` Rafael J. Wysocki
2024-01-23 18:26                   ` Rafael J. Wysocki
2024-01-23 18:59                   ` Russell King (Oracle)
2024-01-23 18:59                     ` Russell King (Oracle)
2024-01-23 18:59                     ` Russell King (Oracle)
2024-01-23 19:27                     ` Rafael J. Wysocki
2024-01-23 19:27                       ` Rafael J. Wysocki
2024-01-23 19:27                       ` Rafael J. Wysocki
2024-01-23 20:09                       ` Russell King (Oracle)
2024-01-23 20:09                         ` Russell King (Oracle)
2024-01-23 20:09                         ` Russell King (Oracle)
2024-01-23 20:17                         ` Rafael J. Wysocki
2024-01-23 20:17                           ` Rafael J. Wysocki
2024-01-23 20:17                           ` Rafael J. Wysocki
2024-01-23 20:57                           ` Russell King (Oracle)
2024-01-23 20:57                             ` Russell King (Oracle)
2024-01-23 20:57                             ` Russell King (Oracle)
2024-01-23 21:12                             ` Russell King (Oracle)
2024-01-23 21:12                               ` Russell King (Oracle)
2024-01-23 21:12                               ` Russell King (Oracle)
2024-01-23 22:05                               ` Rafael J. Wysocki
2024-01-23 22:05                                 ` Rafael J. Wysocki
2024-01-23 22:05                                 ` Rafael J. Wysocki
2024-01-24  8:45                                 ` Russell King (Oracle)
2024-01-24  8:45                                   ` Russell King (Oracle)
2024-01-24  8:45                                   ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 06/21] ACPI: Move acpi_bus_trim_one() before acpi_scan_hot_remove() Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49 ` [PATCH RFC v3 07/21] ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-14 17:43   ` Jonathan Cameron
2023-12-14 17:43     ` Jonathan Cameron
2023-12-14 17:43     ` Jonathan Cameron
2023-12-14 18:03     ` Russell King (Oracle)
2023-12-14 18:03       ` Russell King (Oracle)
2023-12-14 18:03       ` Russell King (Oracle)
2023-12-13 12:49 ` [PATCH RFC v3 08/21] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49   ` Russell King
2023-12-13 12:49 ` [PATCH RFC v3 09/21] ACPI: convert acpi_processor_post_eject() to use IS_ENABLED() Russell King (Oracle)
2023-12-13 12:49   ` Russell King (Oracle)
2023-12-13 12:49   ` Russell King (Oracle)
2023-12-15 16:11   ` Jonathan Cameron
2023-12-15 16:11     ` Jonathan Cameron
2023-12-15 16:11     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 10/21] ACPI: Check _STA present bit before making CPUs not present Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:18   ` Jonathan Cameron
2023-12-15 16:18     ` Jonathan Cameron
2023-12-15 16:18     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 11/21] ACPI: Warn when the present bit changes but the feature is not enabled Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50 ` [PATCH RFC v3 12/21] arm64: acpi: Move get_cpu_for_acpi_id() to a header Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50 ` [PATCH RFC v3 13/21] ACPICA: Add new MADT GICC flags fields Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:23   ` Jonathan Cameron
2023-12-15 16:23     ` Jonathan Cameron
2023-12-15 16:23     ` Jonathan Cameron
2023-12-15 16:53     ` Russell King (Oracle)
2023-12-15 16:53       ` Russell King (Oracle)
2023-12-15 16:53       ` Russell King (Oracle)
2023-12-18  9:23       ` Lorenzo Pieralisi
2023-12-18  9:23         ` Lorenzo Pieralisi
2023-12-18  9:23         ` Lorenzo Pieralisi
2023-12-18 13:14         ` Rafael J. Wysocki
2023-12-18 13:14           ` Rafael J. Wysocki
2023-12-18 13:14           ` Rafael J. Wysocki
2023-12-18 16:28           ` Lorenzo Pieralisi
2023-12-18 16:28             ` Lorenzo Pieralisi
2023-12-18 16:28             ` Lorenzo Pieralisi
2023-12-27 11:15           ` Lorenzo Pieralisi
2023-12-27 11:15             ` Lorenzo Pieralisi
2023-12-27 11:15             ` Lorenzo Pieralisi
2023-12-13 12:50 ` [PATCH RFC v3 14/21] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:33   ` Jonathan Cameron
2023-12-15 16:33     ` Jonathan Cameron
2023-12-15 16:33     ` Jonathan Cameron
2024-01-09 19:27     ` Russell King (Oracle)
2024-01-09 19:27       ` Russell King (Oracle)
2024-01-09 19:27       ` Russell King (Oracle)
2024-01-23 10:08       ` Jonathan Cameron
2024-01-23 10:08         ` Jonathan Cameron
2024-01-23 10:08         ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 15/21] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:38   ` Jonathan Cameron
2023-12-15 16:38     ` Jonathan Cameron
2023-12-15 16:38     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 16/21] arm64: psci: Ignore DENIED CPUs Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:40   ` Jonathan Cameron
2023-12-15 16:40     ` Jonathan Cameron
2023-12-15 16:40     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 17/21] ACPI: add support to register CPUs based on the _STA enabled bit Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-18 13:03   ` Russell King (Oracle)
2023-12-18 13:03     ` Russell King (Oracle)
2023-12-18 13:03     ` Russell King (Oracle)
2024-01-02 14:53     ` Jonathan Cameron
2024-01-02 14:53       ` Jonathan Cameron
2024-01-02 14:53       ` Jonathan Cameron
2024-01-23 10:26       ` Jonathan Cameron
2024-01-23 10:26         ` Jonathan Cameron
2024-01-23 10:26         ` Jonathan Cameron
2024-01-23 13:10         ` Russell King (Oracle)
2024-01-23 13:10           ` Russell King (Oracle)
2024-01-23 13:10           ` Russell King (Oracle)
2024-01-23 14:22           ` Jonathan Cameron
2024-01-23 14:22             ` Jonathan Cameron
2024-01-23 14:22             ` Jonathan Cameron
2024-01-23 14:59             ` Russell King (Oracle)
2024-01-23 14:59               ` Russell King (Oracle)
2024-01-23 14:59               ` Russell King (Oracle)
2023-12-13 12:50 ` [PATCH RFC v3 18/21] ACPI: processor: Only call arch_unregister_cpu() if HOTPLUG_CPU is selected Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 16:50   ` Jonathan Cameron
2023-12-15 16:50     ` Jonathan Cameron
2023-12-15 16:50     ` Jonathan Cameron
2023-12-18 12:58     ` Russell King (Oracle)
2023-12-18 12:58       ` Russell King (Oracle)
2023-12-18 12:58       ` Russell King (Oracle)
2024-01-23 10:29       ` Jonathan Cameron
2024-01-23 10:29         ` Jonathan Cameron
2024-01-23 10:29         ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 19/21] arm64: document virtual CPU hotplug's expectations Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:04   ` Jonathan Cameron [this message]
2023-12-15 17:04     ` Jonathan Cameron
2023-12-15 17:04     ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 20/21] ACPI: Add _OSC bits to advertise OS support for toggling CPU present/enabled Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:12   ` Jonathan Cameron
2023-12-15 17:12     ` Jonathan Cameron
2023-12-15 17:12     ` Jonathan Cameron
2024-01-02 13:07     ` Jose Marinho
2024-01-02 13:07       ` Jose Marinho
2024-01-02 13:07       ` Jose Marinho
2024-01-02 15:16       ` Jonathan Cameron
2024-01-02 15:16         ` Jonathan Cameron
2024-01-02 15:16         ` Jonathan Cameron
2024-01-02 15:35         ` Jose Marinho
2024-01-02 15:35           ` Jose Marinho
2024-01-02 15:35           ` Jose Marinho
2024-01-23 10:51           ` Jonathan Cameron
2024-01-23 10:51             ` Jonathan Cameron
2024-01-23 10:51             ` Jonathan Cameron
2023-12-13 12:50 ` [PATCH RFC v3 21/21] cpumask: Add enabled cpumask for present CPUs that can be brought online Russell King
2023-12-13 12:50   ` Russell King
2023-12-13 12:50   ` Russell King
2023-12-15 17:18   ` Jonathan Cameron
2023-12-15 17:18     ` Jonathan Cameron
2023-12-15 17:18     ` Jonathan Cameron
2023-12-18 12:14     ` Russell King (Oracle)
2023-12-18 12:14       ` Russell King (Oracle)
2023-12-18 12:14       ` Russell King (Oracle)
2024-01-02 15:19       ` Jonathan Cameron
2024-01-02 15:19         ` Jonathan Cameron
2024-01-02 15:19         ` Jonathan Cameron
2023-12-15 19:40   ` Thomas Gleixner
2023-12-15 19:40     ` Thomas Gleixner
2023-12-15 19:40     ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231215170428.00000d81@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=acpica-devel@lists.linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=jean-philippe@linaro.org \
    --cc=jianyong.wu@arm.com \
    --cc=justin.he@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=loongarch@lists.linux.dev \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=salil.mehta@huawei.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.