Hi Salil,
(replying to an off-list email from Salil...)
You suggested proposing a talk on the hotplug stuff for kvm forum, yes we can co-present
it, but we'll need to discuss it here. Let me know if you plan to submit this today, or I
need to do it. I finish work at roughly 6pm UK time.
For a title I suggest: "Supporting hotplug on architectures that don't".
I had a stab at the abstract before you wrote yours:
vCPU hotplug is used by orchestration managers to pre-create VMs, and scale them correctly
when a workload is deployed. Architecture support for adding CPUs to an existing system is
complex, and not feasible to standardise without hardware.
This talk covers the use-cases, difficulties, and a proposed way of supporting this on
architectures that lack physical CPU hotplug.
Comparing it to what you've written.
I'm not sure the abstract needs any technical details. We can mention the history in the
talk, but I don't think its useful to dwell on it.
We'll need to come up with slides, my suggested outline is something like:
* The x86 history: CPU hotplug being supported before virtualisation.
* Why vCPU hotplug is used for on x86 (kata containers, kubernetes, cloud orchestration)
* Why that ACPI mechanism wouldn't work for arm64: we can't support hotplug virtualisation
without real hardware. (not future proof)
* What the actual requirements are.
* Changes to PSCI and arm64-linux to support all this in a future proof way.
* How physical CPU hotplug would work at the same time
[* Slides on the Qemu details and complexities.]
Something to be aware is of is that arm want a clear split in the presentation between the
kernel side of it, and your Qemu work.
Thanks,
James
Dear all,
I am writing to invite you to a public call on Wednesday, 29/Mar/2023, from
10:00 to 10:50 AM (GMT+8) to discuss Bigtop and OpenEuler support. The
purpose of this call is to share updates and gather feedback on our efforts
to support these technologies.
This call is open to anyone who is interested in these topics, so please
feel free to forward this invitation to your colleagues and networks.
To join the call, please use the following details:
Date: 29/Mar/2023
Time: 10:00 to 10:50 AM (GMT+8)
Zoom Link: https://linaro-org.zoom.us/j/98826320072
We look forward to your participation and feedback.
Best regards,
Guodong Xu
PS: drafted by ChatGPT and reviewed by me. :)
Hi,
It's soon time for another LOC monthly meeting. For time and connection
details see the calendar at https://www.trustedfirmware.org/meetings/
If you have any topics you'd like to discuss, please let us know and
we can schedule them.
Thanks,
Jens
Ha :) I forgot to post that.
Wednesday, March 15⋅10:00 – 10:40am
On Wed, Mar 15, 2023 at 9:01 AM Kangkang Shen <kangkang.shen(a)futurewei.com>
wrote:
> When is the meeting?
>
> -----Original Message-----
> From: Guodong Xu via Linaro-open-discussions <
> linaro-open-discussions(a)op-lists.linaro.org>
> Sent: Tuesday, March 14, 2023 5:57 PM
> To: linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org>
> Subject: [Linaro-open-discussions] Sync-up of OpenEuler / Bigtop progress
>
> Hi, All
>
> You are invited to join this meeting for an OpenEuler / Bigtop progress
> discussion.
>
> Guodong Xu is inviting you to a scheduled Zoom meeting.
>
> Join Zoom Meeting
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinaro-or…
>
> Meeting ID: 947 2011 9602
> One tap mobile
> +16694449171,,94720119602# US
> +16699009128,,94720119602# US (San Jose)
>
> Dial by your location
> +1 669 444 9171 US
> +1 669 900 9128 US (San Jose)
> +1 346 248 7799 US (Houston)
> +1 719 359 4580 US
> +1 253 205 0468 US
>
>
> Thank you.
> BR,
> Guodong Xu
> Linaro
> --
> Linaro-open-discussions mailing list --
> linaro-open-discussions(a)op-lists.linaro.org
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcollabora…
>
Hi, All
You are invited to join this meeting for an OpenEuler / Bigtop progress
discussion.
Guodong Xu is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://linaro-org.zoom.us/j/94720119602
Meeting ID: 947 2011 9602
One tap mobile
+16694449171,,94720119602# US
+16699009128,,94720119602# US (San Jose)
Dial by your location
+1 669 444 9171 US
+1 669 900 9128 US (San Jose)
+1 346 248 7799 US (Houston)
+1 719 359 4580 US
+1 253 205 0468 US
Thank you.
BR,
Guodong Xu
Linaro
Hi James,
> > Qemu isn't responding with PSCI_DENIED when CPUs are forbidden. ('SUCCESS' means you
> > hit a 5 second timeout in the guest, on each CPU)
I have tested the straight forward case and it works.
Could you please elaborate on this so that I can look into the issue?
Thanks
Salil
Hi all，
Do we have any topic for next open discussion（Feb 28th）？
Thanks：）
Joyce
> 在 2023年2月24日，上午8:00，linaro-open-discussions-request@op-lists.linaro.org 写道：
>
> Send Linaro-open-discussions mailing list submissions to
> linaro-open-discussions(a)op-lists.linaro.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> linaro-open-discussions-request(a)op-lists.linaro.org
>
> You can reach the person managing the list at
> linaro-open-discussions-owner(a)op-lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linaro-open-discussions digest..."
>
> Today's Topics:
>
> 1. Re: [RFC PATCH v0.1 22/25] ACPI: add support to register CPUs based on the _STA enabled bit
> (Vishnu Pajjuri)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 Feb 2023 11:40:43 +0530
> From: Vishnu Pajjuri <vishnu(a)amperemail.onmicrosoft.com>
> Subject: [Linaro-open-discussions] Re: [RFC PATCH v0.1 22/25] ACPI:
> add support to register CPUs based on the _STA enabled bit
> To: James Morse <james.morse(a)arm.com>,
> linaro-open-discussions(a)op-lists.linaro.org
> Message-ID:
> <6010811b-6c26-ad52-2a15-f5a55972c108(a)amperemail.onmicrosoft.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi James/Salil,
>
> On 31-08-2022 16:39, James Morse wrote:
>> acpi_processor_get_info() registers all present CPUs. Registering a
>> CPU is what creates the sysfs entries and triggers the udev
>> notifications.
>>
>> arm64 virtual machines that support 'virtual cpu hotplug' use the
>> enabled bit to indicate whether the CPU can be brought online, as
>> the existing ACPI tables require all hardware to be described and
>> present.
>>
>> If firmware describes a CPU as present, but disabled, skip the
>> registration. Such CPUs are present, but can't be brought online for
>> whatever reason. (e.g. firmware/hypervisor policy).
>>
>> Once firmware sets the enabled bit, the CPU can be registered and
>> brought online by user-space. Online CPUs, or CPUs that are missing
>> an _STA method must always be registered.
>>
>> Signed-off-by: James Morse <james.morse(a)arm.com>
>> ---
>> drivers/acpi/acpi_processor.c | 31 ++++++++++++++++++++++++++++++-
>> 1 file changed, 30 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
>> index 1bd6e4b8ab66..42521d89c378 100644
>> --- a/drivers/acpi/acpi_processor.c
>> +++ b/drivers/acpi/acpi_processor.c
>> @@ -194,6 +194,32 @@ static int acpi_processor_make_present(struct acpi_processor *pr)
>> return ret;
>> }
>>
>> +static int acpi_processor_make_enabled(struct acpi_processor *pr)
>> +{
>> + unsigned long long sta;
>> + acpi_status status;
>> + bool present, enabled;
>> +
>> + if (!acpi_has_method(pr->handle, "_STA"))
>> + return arch_register_cpu(pr->id);
>> +
>> + status = acpi_evaluate_integer(pr->handle, "_STA", NULL, &sta);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + present = sta & ACPI_STA_DEVICE_PRESENT;
>> + enabled = sta & ACPI_STA_DEVICE_ENABLED;
>> +
>> + if (cpu_online(pr->id) && (!present || !enabled)) {
>> + pr_err_once(FW_BUG "CPU %u is online, but described as not present or disabled!\n", pr->id);
>> + add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
>> + } else if (!present || !enabled) {
>> + return -ENODEV;
>> + }
>> +
>> + return arch_register_cpu(pr->id);
>> +}
>> +
>> static int acpi_processor_get_info(struct acpi_device *device)
>> {
>> union acpi_object object = { 0 };
>> @@ -271,7 +297,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>> }
>>
>> if (!invalid_logical_cpuid(pr->id) && cpu_present(pr->id)) {
>> - int ret = arch_register_cpu(pr->id);
>> + int ret = acpi_processor_make_enabled(pr);
>>
>> if (ret)
>> return ret;
>> @@ -479,6 +505,9 @@ static void acpi_processor_remove(struct acpi_device *device)
>> acpi_processor_make_not_present(device);
>> return;
>> }
>> +
>> + if (cpu_present(pr->id) && !(sta & ACPI_STA_DEVICE_ENABLED))
>> + arch_unregister_cpu(pr->id);
>> }
>>
>> #ifdef CONFIG_X86
>
> Enumeration failure while trying to hot plug vcpus after guest reboot
>
> Following sequence of steps causes the issue
>
> 1. Boot VM with max 80 vcpus and current 72 vcpus(For example)
> 2. hot plug 3 more vcpus
> # virsh setvcpus vm2 75 --live
> 3. hot unplug 3 vcpus ( which were added earlier )
> # virsh setvcpus vm2 72 --live
> 4. reboot VM
> # reboot
> 5. Again try to hot plug 3 vcpus -- ERROR
> # virsh setvcpus vm2 75 --live
> [ 47.367823] acpi ACPI0007:48: Enumeration failure
> [ 47.565173] acpi ACPI0007:49: Enumeration failure
> [ 47.703423] acpi ACPI0007:4a: Enumeration failure
>
>
> I have tested the above scenario with following git repos
>
> https://github.com/salil-mehta/qemu/tree/virt-cpuhp-armv8/rfc-v1-port290920…
>
> https://github.com/salil-mehta/linux/tree/virt-cpuhp-arm64/rfc-v2/jmorse-va…
> https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/rfc/v/…
>
> I observed the following sequence while doing hotplug and unplug
>
> When we do hotplug, making vcpu as *present*(_STA.Pres=1) and
> *enabled*(_STA.Enabled=1)
> When we do hot unplug, we just *disabled*(_STA.Enabled=0) vcpu but not
> *removed*(_STA.Pres=1)
>
> In such a case CPU shall still be present at the firmware/VMM level and
> could be kept disabled
> i.e. _STA.Enable=0 and _STA.Present=1
>
> After reboot, system is trying to enumerate vcpu(as *present*(_STA.Pres=1))
> and it is marking flags flags.initialized = true and flags.visited = true
>
> as the vcpu *disabled*(_STA.Enabled=0), vcpu has been made not present
> and flags flags.initialized and flags.visited were not cleared
>
>
> And following fix resolves the issue
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 558664d169fc..e93b933cb8a4 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -2158,6 +2158,9 @@ static int acpi_scan_attach_handler(struct
> acpi_device *device)
> break;
>
> device->handler = NULL;
> + device->flags.initialized = false;
> + acpi_device_clear_enumerated(device);
> + device->flags.power_manageable = 0;
> if (ret < 0)
> break;
> }
>
> _Regards_,
> -Vishnu.
>
> ------------------------------
>
> Subject: Digest Footer
>
> Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org
> To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org
>
>
> ------------------------------
>
> End of Linaro-open-discussions Digest, Vol 29, Issue 6
> ******************************************************
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 Salil,
I've rebased the online-policy/hotplug stuff onto Oliver's preferred way of doing PSCI in
userspace. The whole tree is here:
https://gitlab.arm.com/linux-arm/linux-jm/-/tree/virtual_cpu_hotplug/snapsh…
I'll probably only post the in-guest parts, as the combined thing is getting too big.
Is there any chance you could update the Qemu support for this, so that folk can play with
it when its next posted?
I've tested the KVM side of it with PSCI support for kvmtool, which is here:
https://gitlab.arm.com/linux-arm/kvmtool-jm/-/tree/psci_in_userpsace/rfc/v1
The upshot is the CAP's disappear, and the device get/set attr has to be used against the
VM fd to setup an SMC-CC filter for PSCI. Hopefully the kvmtool example makes your life
easier.
Any feedback on how easy this is for Qemu to use would be great.
I've not looked into Vishnu's bug report yet.
Thanks,
James
