Hi Gustavo, > On 18 Oct 2024, at 17:57, Gustavo Romero <gustavo.rom...@linaro.org> wrote: > > Hi Miguel, > > On 10/15/24 15:41, Miguel Luis wrote: >> Hi Salil, >> I’ve ran the usual tests successfully of hotplug/unplug from the number of >> cold-booted cpus up to maxcpus and migration on ARM. Please feel free to add: > > Do you mind sharing what cpus you used for your tests? >
Not at all. I’ve used -cpu host and -cpu max. I had used RFC-v5 from [1] in order to test this patchset as they are at the base of it. > Did you use tcg or kvm for the tests? I’ve used both in the following configurations: -M virt -accel kvm -cpu host -M virt,gic_version=3 -accel kvm -cpu host -M virt,gic_version=3 -accel tcg -cpu max And -M virt -accel tcg -cpu max This last one presented defects in QEMU on behalf of RFC-V5 but, if you don’t mind, instead of me transcribing everything here, could you please take a look at [2] ? I could have given more detail from start, apologies for any confusion on my part. Thanks, Miguel [1]: https://github.com/salil-mehta/qemu/commits/virt-cpuhp-armv8/rfc-v5/ [2]: https://lore.kernel.org/qemu-devel/30478b18-932d-413c-bff0-5fd70510d...@oracle.com/ > > Thanks! > > > Cheers, > Gustavo > >> Tested-by: Miguel Luis <miguel.l...@oracle.com> >> Thanks >> Miguel >>> On 14 Oct 2024, at 19:22, Salil Mehta <salil.me...@huawei.com> wrote: >>> >>> Certain CPU architecture specifications [1][2][3] prohibit changes to the >>> CPUs >>> *presence* after the kernel has booted. This is because many system >>> initializations depend on the exact CPU count at boot time and do not >>> expect it >>> to change afterward. For example, components like interrupt controllers >>> that are >>> closely coupled with CPUs, or various per-CPU features, may not support >>> configuration changes once the kernel has been initialized. >>> >>> This requirement poses a challenge for virtualization features like vCPU >>> hotplug. To address this, changes to the ACPI AML are necessary to update >>> the >>> `_STA.PRES` (presence) and `_STA.ENA` (enabled) bits accordingly during >>> guest >>> initialization, as well as when vCPUs are hot-plugged or hot-unplugged. The >>> presence of unplugged vCPUs may need to be deliberately *simulated* at the >>> ACPI >>> level to maintain a *persistent* view of vCPUs for the guest kernel. >>> >>> This patch set introduces the following features: >>> >>> 1. ACPI Interface with Explicit PRESENT and ENABLED CPU States: It allows >>> the >>> guest kernel to evaluate these states using the `_STA` ACPI method. >>> >>> 2. Initialization of ACPI CPU States: These states are initialized during >>> `machvirt_init` and when vCPUs are hot-(un)plugged. This enables >>> hotpluggable >>> vCPUs to be exposed to the guest kernel via ACPI. >>> >>> 3. Support for Migrating ACPI CPU States: The patch set ensures the >>> migration of >>> the newly introduced `is_{present,enabled}` ACPI CPU states to the >>> destination VM. >>> >>> The approach is flexible enough to accommodate ARM-like architectures that >>> intend to implement vCPU hotplug functionality. It is suitable for >>> architectures >>> facing similar constraints to ARM or those that plan to implement vCPU >>> hotplugging independently of hardware support (if available). >>> >>> This patch set is derived from the ARM-specific vCPU hotplug implementation >>> [4] >>> and includes migration components adaptable to other architectures, >>> following >>> suggestions [5] made by Igor Mammedov <imamm...@redhat.com>. >>> >>> It can be applied independently, ensuring compatibility with existing >>> hotplug >>> support in other architectures. I have tested this patch set in conjunction >>> with >>> the ARM-specific vCPU hotplug changes (included in the upcoming RFC V5 >>> [6]), and >>> everything worked as expected. I kindly request maintainers of other >>> architectures to provide a "Tested-by" after running their respective >>> regression >>> tests. >>> >>> Many thanks! >>> >>> >>> References: >>> [1] KVMForum 2023 Presentation: Challenges Revisited in Supporting Virt CPU >>> Hotplug on >>> architectures that don’t Support CPU Hotplug (like ARM64) >>> a. Kernel Link: >>> https://kvm-forum.qemu.org/2023/KVM-forum-cpu-hotplug_7OJ1YyJ.pdf >>> b. Qemu Link: >>> https://kvm-forum.qemu.org/2023/Challenges_Revisited_in_Supporting_Virt_CPU_Hotplug_-__ii0iNb3.pdf >>> [2] KVMForum 2020 Presentation: Challenges in Supporting Virtual CPU >>> Hotplug on >>> SoC Based Systems (like ARM64) >>> Link: https://kvmforum2020.sched.com/event/eE4m >>> [3] Check comment 5 in the bugzilla entry >>> Link: https://bugzilla.tianocore.org/show_bug.cgi?id=4481#c5 >>> [4] [PATCH RFC V4 00/33] Support of Virtual CPU Hotplug for ARMv8 Arch >>> Link: >>> https://lore.kernel.org/qemu-devel/20241009031815.250096-1-salil.me...@huawei.com/T/#mf32be203baa568a871dc625b732f666a4c4f1e68 >>> [5] Architecture agnostic ACPI VMSD state migration (Discussion) >>> Link: >>> https://lore.kernel.org/qemu-devel/20240715155436.577d3...@imammedo.users.ipa.redhat.com/ >>> [6] Upcoming RFC V5, Support of Virtual CPU Hotplug for ARMv8 Arch >>> Link: https://github.com/salil-mehta/qemu/commits/virt-cpuhp-armv8/rfc-v5 >>> >>> Salil Mehta (4): >>> hw/acpi: Initialize ACPI Hotplug CPU Status with Support for vCPU >>> `Persistence` >>> hw/acpi: Update ACPI CPU Status `is_{present, enabled}` during vCPU >>> hot(un)plug >>> hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI >>> _STA.{PRES,ENA} Bits >>> hw/acpi: Populate vCPU Hotplug VMSD to migrate `is_{present,enabled}` >>> states >>> >>> cpu-target.c patches.vcpuhp.rfc-v5.arch.agnostic.acpi | 1 >>> + >>> hw/acpi/cpu.c | 70 +++++++++++++++++++++++++++++++--- >>> hw/acpi/generic_event_device.c | 11 ++++++ >>> include/hw/acpi/cpu.h | 21 ++++++++++ >>> include/hw/core/cpu.h | 21 ++++++++++ >>> 5 files changed, 119 insertions(+), 5 deletions(-) >>> >>> -- >>> 2.34.1 >>> >
