요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. 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 topology 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.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
arm64 CPU hotplug의 범위
1-14이 문서의 SPDX license는 `GPL-2.0`이며 Sphinx anchor는 `_cpuhp_index`입니다. Arm64에서 CPU hotplug는 흔히 PSCI를 이용해 kernel이 CPU를 online/offline하는 일을 뜻하지만, 이 문서는 boot 당시 사용할 수 없던 CPU를 ACPI firmware가 나중에 system에 추가하도록 허용하는 경우를 다룹니다.
여기서 `possible`과 `present`는 Linux가 보는 CPU 상태를 의미합니다.
물리 system: boot 시 present가 아닌 CPU
15-41물리 system에서 hotplug하려면 `possible`이지만 `present`가 아닌 CPU를 나중에 `present`로 바꿔야 합니다. 실행 중인 dual-socket machine의 한 socket package를 교체하는 경우가 예입니다. Arm64는 이 동작을 지원하지 않습니다.
Arm64에서 CPU는 독립된 단일 device가 아니라 system의 한 부분입니다. 실행 중 CPU를 물리적으로 추가하거나 제거하는 system이 없고, ACPI도 그 구성을 충분히 기술할 수 없습니다.
새 CPU에는 새 cache가 따라오지만 platform cache topology는 정적 `PPTT`에 기록됩니다. CPU 사이 cache 공유 관계는 자동 발견할 수 없어 firmware가 설명해야 합니다.
각 CPU의 GIC redistributor는 boot 중 driver가 접근해 system-wide 지원 기능을 발견해야 합니다. ACPI `MADT GICC` 구조는 disabled CPU와 연결된 redistributor를 기술할 수 있지만, `always on`이 아니라는 사실만 나타낼 뿐 실제 접근 가능 여부는 설명하지 못합니다.
따라서 arm64 ACPI table은 기술된 모든 자원이 `present`라고 가정합니다.
가상 system: boot 시 enabled가 아닌 CPU
42-79가상 system은 system이 앞으로 가질 모든 property를 boot 시점에 기술할 수 있고 device가 emulated되므로 power-domain 제약도 없습니다. 따라서 virtual CPU hotplug는 지원됩니다.
물리 hotplug와 달리 모든 resource는 `present`로 기술되지만 firmware가 CPU를 disabled로 표시할 수 있습니다. Firmware는 CPU의 online/offline 동작만 제어합니다. 예를 들어 VM은 CPU 하나로 boot한 뒤 cloud orchestrator가 workload를 배치할 때 CPU를 더 받을 수 있습니다. VM에서는 VMM, 예를 들어 Qemu가 firmware 역할을 합니다.
Virtual hotplug는 어떤 CPU를 online할 수 있는지 결정하는 firmware policy입니다. Firmware는 PSCI return code, 예를 들어 `DENIED`로 policy를 강제할 수 있습니다.
ACPI table은 VM의 모든 resource를 기술해야 합니다. Boot 시점이나 이후에 비활성화할 CPU는 `MADT GICC`에서 `enabled`를 끄고, 나중에 활성화할 수 있음을 나타내는 `online capable` bit를 설정해야 합니다. Boot CPU는 반드시 `enabled`여야 하며 redistributor는 `always on` GICR 구조로 기술합니다.
`online capable`이지만 `enabled`가 아닌 CPU는 DSDT Processor object의 `_STA` method로 enabled 상태가 될 수 있습니다. 가상 system의 `_STA`는 CPU를 항상 `present`로 보고해야 하며, firmware policy 변경은 `device-check` 또는 `eject-request`로 OS에 알릴 수 있습니다.
정적 table에서 `enabled`로 기술된 CPU의 `_STA`를 firmware가 동적으로 바꾸면 안 됩니다. `kexec` 같은 soft restart는 정적 table에서 system property를 다시 읽으므로 실행 중인 system과 불일치하면 오동작할 수 있습니다. Linux는 boot 후반에 `_STA`에서 동적 property를 다시 발견합니다.
요약과 해설
cpu-hotplug.rst:1-79Arm64 ACPI는 runtime 물리 CPU 추가를 기술할 수 없지만, VM은 모든 resource를 처음부터 `present`로 선언하고 firmware policy로 `enabled`만 바꾸는 방식의 virtual hotplug를 지원합니다.
두 방식은 resource가 system에 존재하는 시점부터 다릅니다.
정적 ACPI 정보와 동적 `_STA` 정책이 맡는 역할을 구분합니다.