Hello!
v0.1? Yeah, this is v0 from gitlab, rebased onto v6.0-rc3.
This series has only been lightly tested....
---
Hello!
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 out of the arch code by using
GENERIC_CPU_DEVICES, then into 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, 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, 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'd need 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.
I assume all x86 firmware vendors set the ENABLED bit in the CPU object's _STA
method. This code is unconditionally enabled for all ACPI architectures.
If there are problems with firmware tables on some devices, the CPUs will
already be online by the time the acpi_processor_make_enabled() is called.
A mismatch here causes a firmware-bug message and kernel taint. This should
only affect people with broken firmware who also boot with maxcpus=1, and
bring CPUs online later.
I had a go at switching the remaining architectures over to GENERIC_CPU_DEVICES,
so that the Kconfig symbol can be removed, but I got stuck with powerpc
and s390.
Thanks,
James Morse (22):
ACPI: Move ACPI_HOTPLUG_CPU to be enabled per architecture
drivers: base: Use present CPUs in GENERIC_CPU_DEVICES
drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden
drivers: base: Move node_dev_init() before cpu_dev_init()
arm64: setup: Switch over to GENERIC_CPU_DEVICES using
arch_register_cpu()
ia64/topology: Switch over to GENERIC_CPU_DEVICES
x86/topology: Switch over to GENERIC_CPU_DEVICES
LoongArch: Switch over to GENERIC_CPU_DEVICES
ACPI: processor: Register all CPUs from acpi_processor_get_info()
ACPI: Rename ACPI_HOTPLUG_CPU to include 'present'
ACPI: Rename acpi_processor_hotadd_init and remove pre-processor
guards
ACPI: Check _STA present bit before making CPUs not present
ACPI: Warn when the present bit changes but the feature is not enabled
drivers: base: Implement weak arch_unregister_cpu()
LoongArch: Use the __weak version of arch_unregister_cpu()
arm64: acpi: Move get_cpu_for_acpi_id() to a header
ACPICA: Add new MADT GICC flags fields [code first?]
arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a
helper
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
ACPI: add support to register CPUs based on the _STA enabled bit
arm64: document virtual CPU hotplug's expectations
Jean-Philippe Brucker (3):
arm64: psci: Ignore DENIED CPUs
KVM: arm64: Pass hypercalls to userspace
KVM: arm64: Pass PSCI calls to userspace
Documentation/arm64/cpu-hotplug.rst | 79 ++++++++++++++++++
Documentation/arm64/index.rst | 1 +
Documentation/virt/kvm/api.rst | 31 ++++++-
Documentation/virt/kvm/arm/hypercalls.rst | 1 +
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 11 +++
arch/arm64/include/asm/cpu.h | 1 -
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kernel/acpi_numa.c | 11 ---
arch/arm64/kernel/psci.c | 2 +-
arch/arm64/kernel/setup.c | 13 +--
arch/arm64/kernel/smp.c | 5 +-
arch/arm64/kvm/arm.c | 15 +++-
arch/arm64/kvm/hypercalls.c | 28 ++++++-
arch/arm64/kvm/psci.c | 13 +++
arch/ia64/Kconfig | 2 +
arch/ia64/include/asm/acpi.h | 2 +-
arch/ia64/include/asm/cpu.h | 11 ---
arch/ia64/kernel/acpi.c | 6 +-
arch/ia64/kernel/setup.c | 2 +-
arch/ia64/kernel/topology.c | 35 ++------
arch/loongarch/Kconfig | 2 +
arch/loongarch/kernel/topology.c | 31 +------
arch/x86/Kconfig | 2 +
arch/x86/include/asm/cpu.h | 6 --
arch/x86/kernel/acpi/boot.c | 4 +-
arch/x86/kernel/topology.c | 19 +----
drivers/acpi/Kconfig | 5 +-
drivers/acpi/acpi_processor.c | 99 ++++++++++++++++-------
drivers/acpi/processor_core.c | 2 +-
drivers/base/cpu.c | 21 +++--
drivers/base/init.c | 2 +-
drivers/firmware/psci/psci.c | 2 +
drivers/irqchip/irq-gic-v3.c | 38 +++++----
include/acpi/actbl2.h | 1 +
include/kvm/arm_hypercalls.h | 1 +
include/kvm/arm_psci.h | 4 +
include/linux/acpi.h | 10 ++-
include/linux/cpu.h | 6 ++
include/uapi/linux/kvm.h | 2 +
40 files changed, 339 insertions(+), 190 deletions(-)
create mode 100644 Documentation/arm64/cpu-hotplug.rst
--
2.30.2
Hi all,
in the meeting held today we decided to go ahead as follows in relation
to ARM64 virt CPU hotplug patches and QEmu changes:
- James requires QEmu changes to test his branch[1]
- Huawei (Salil) agreed to upgrade the QEmu patches to the latest ACPI
specs (and James' code [1])
- QEmu updates will be given with a branch/link in reply to this email thread
so that James can complete [1] testing against them
- Any testing, bug report, communication will take place through this
mailing list before public posting on a kernel ML, so please keep an
eye on this thread if you'd like to collaborate/help
- It would be good to get some feedback from containers/kubernetes
developers on the full software stack - after all we are making these
changes to enable the ecosystem
Please chime in if I forgot something or reach out, all comments are
welcome.
Lorenzo
[1] https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/rfc/v0
Linaro Open Discussions monthly meeting
Tuesday 23 Aug 2022 ⋅ 22:00 – 23:00
Hong Kong Standard Time
Location
https://linaro-org.zoom.us/j/95682500341https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250…
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议
https://linaro-org.zoom.us/j/95682500341
会议号:956 8250 0341
手机一键拨号
+16699009128,,95682500341# 美国 (San Jose)
+13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号
+1 669 900 9128 美国 (San Jose)
+1 346 248 7799 美国 (Houston)
+1 253 215 8782 美国 (Tacoma)
+1 646 558 8656 美国 (New York)
+1 301 715 8592 美国 (Washington DC)
+1 312 626 6799 美国 (Chicago)
888 788 0099 美国 免费
877 853 5247 美国 免费
会议号:956 8250 0341
查找本地号码:https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests
lorenzo.pieralisi(a)arm.com
ilkka(a)os.amperecomputing.com
jonathan.cameron(a)huawei.com
salil.mehta(a)huawei.com
james.morse(a)arm.com
Mike Holmes
linaro-open-discussions(a)op-lists.linaro.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv…
Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organiser, be added to the guest list, invite others regardless of
their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi folks,
I would like to take advantage of the upcoming call on tuesday to
resume the virt CPU hotplug topic and sync-up on that.
It would probably be great if we can make the time more US friendly,
given that there are folks who want to join from the US but I understand
it then becomes problematic for other people to join.
Please let me know if we can have a meeting on tuesday and at
what time.
Thanks,
Lorenzo