qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Salil Mehta via <qemu-devel@nongnu.org>
To: maobibo <maobibo@loongson.cn>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"mst@redhat.com" <mst@redhat.com>
Cc: "maz@kernel.org" <maz@kernel.org>,
	"jean-philippe@linaro.org" <jean-philippe@linaro.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
	"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	"richard.henderson@linaro.org" <richard.henderson@linaro.org>,
	"imammedo@redhat.com" <imammedo@redhat.com>,
	"andrew.jones@linux.dev" <andrew.jones@linux.dev>,
	"david@redhat.com" <david@redhat.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"will@kernel.org" <will@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"gshan@redhat.com" <gshan@redhat.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"borntraeger@linux.ibm.com" <borntraeger@linux.ibm.com>,
	"alex.bennee@linaro.org" <alex.bennee@linaro.org>,
	"npiggin@gmail.com" <npiggin@gmail.com>,
	"harshpb@linux.ibm.com" <harshpb@linux.ibm.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"darren@os.amperecomputing.com" <darren@os.amperecomputing.com>,
	"ilkka@os.amperecomputing.com" <ilkka@os.amperecomputing.com>,
	"vishnu@os.amperecomputing.com" <vishnu@os.amperecomputing.com>,
	"karl.heubaum@oracle.com" <karl.heubaum@oracle.com>,
	"miguel.luis@oracle.com" <miguel.luis@oracle.com>,
	 "salil.mehta@opnsrc.net" <salil.mehta@opnsrc.net>,
	zhukeqian <zhukeqian1@huawei.com>,
	"wangxiongfeng (C)" <wangxiongfeng2@huawei.com>,
	"wangyanan (Y)" <wangyanan55@huawei.com>,
	"jiakernel2@gmail.com" <jiakernel2@gmail.com>,
	"lixianglai@loongson.cn" <lixianglai@loongson.cn>,
	"shahuang@redhat.com" <shahuang@redhat.com>,
	"zhao1.liu@intel.com" <zhao1.liu@intel.com>,
	Linuxarm <linuxarm@huawei.com>,
	"gustavo.romero@linaro.org" <gustavo.romero@linaro.org>
Subject: RE: [PATCH V1 0/4] Arch agnostic ACPI changes to support vCPU Hotplug (on Archs like ARM)
Date: Tue, 15 Oct 2024 14:31:29 +0000	[thread overview]
Message-ID: <a00e18f4324b40a0b54de4bfbc6d67c2@huawei.com> (raw)
In-Reply-To: <3b0b1033-36eb-6180-1363-f76083a32ce0@loongson.cn>

HI Bibo,

>  From: maobibo <maobibo@loongson.cn>
>  Sent: Tuesday, October 15, 2024 4:31 AM
>  To: Salil Mehta <salil.mehta@huawei.com>; qemu-devel@nongnu.org;
>  qemu-arm@nongnu.org; mst@redhat.com
>  
>  With cpu-add/cpu-del command tested on LoongArch system, no migration
>  tested. There is no negative influence with LoongArch cpu hotplug.

Thanks for the confirmation. 

Just curious are guys still using cpu-{add,del} interface for vCPU hotplug?
I thought it was deprecated for device_{add,del}?

https://wiki.qemu.org/Features/CPUHotplug
https://www.qemu.org/docs/master/system/cpu-hotplug.html


Thanks
Salil.

>  
>  Regards
>  Bibo Mao
>  
>  On 2024/10/15 上午3:22, Salil Mehta via 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
>  <imammedo@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_Vir
>  > t_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.mehta
>  > @huawei.com/T/#mf32be203baa568a871dc625b732f666a4c4f1e68
>  > [5] Architecture agnostic ACPI VMSD state migration (Discussion)
>  >      Link:
>  > https://lore.kernel.org/qemu-
>  devel/20240715155436.577d34c5@imammedo.us
>  > ers.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(-)
>  >


  reply	other threads:[~2024-10-15 14:31 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-14 19:22 [PATCH V1 0/4] Arch agnostic ACPI changes to support vCPU Hotplug (on Archs like ARM) Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 1/4] hw/acpi: Initialize ACPI Hotplug CPU Status with Support for vCPU `Persistence` Salil Mehta via
2024-10-16 21:01   ` Gustavo Romero
2024-10-21 20:50     ` Salil Mehta
2024-10-17  5:27   ` Gavin Shan
2024-10-21 21:19     ` Salil Mehta
2024-10-17  5:35   ` Gavin Shan
2024-10-17 20:25   ` Gustavo Romero
2024-10-21 21:22     ` Salil Mehta
2024-10-18 14:11   ` Igor Mammedov
2024-10-21 21:50     ` Salil Mehta
2024-10-25 13:52       ` Igor Mammedov
2024-11-01 10:53         ` Salil Mehta via
2024-11-04 11:43           ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 2/4] hw/acpi: Update ACPI CPU Status `is_{present, enabled}` during vCPU hot(un)plug Salil Mehta via
2024-10-18 14:18   ` Igor Mammedov
2024-10-22 23:02     ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present, enabled} states in ACPI _STA.{PRES, ENA} Bits Salil Mehta via
2024-10-18  5:12   ` [PATCH V1 3/4] hw/acpi: Reflect ACPI vCPU {present,enabled} states in ACPI _STA.{PRES,ENA} Bits Zhao Liu
2024-10-18 14:19     ` Igor Mammedov
2024-10-22 23:50       ` Salil Mehta via
2024-10-22 23:45     ` Salil Mehta via
2024-10-18 14:24   ` Igor Mammedov
2024-10-22 23:57     ` Salil Mehta via
2024-10-21  2:09   ` Gustavo Romero
2024-10-23  1:01     ` Salil Mehta via
2024-10-14 19:22 ` [PATCH V1 4/4] hw/acpi: Populate vCPU Hotplug VMSD to migrate `is_{present, enabled}` states Salil Mehta via
2024-10-18 14:31   ` [PATCH V1 4/4] hw/acpi: Populate vCPU Hotplug VMSD to migrate `is_{present,enabled}` states Igor Mammedov
2024-10-22 23:22     ` Salil Mehta via
2024-10-15  3:30 ` [PATCH V1 0/4] Arch agnostic ACPI changes to support vCPU Hotplug (on Archs like ARM) maobibo
2024-10-15 14:31   ` Salil Mehta via [this message]
2024-10-16  6:00     ` maobibo
2024-10-15 18:41 ` Miguel Luis
2024-10-18 17:57   ` Gustavo Romero
2024-10-21  8:04     ` Miguel Luis
2024-10-22 12:32       ` Gustavo Romero
2024-10-18 14:46 ` Igor Mammedov
2024-10-21  2:33   ` Gustavo Romero
2024-10-23  1:50   ` Salil Mehta via

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=a00e18f4324b40a0b54de4bfbc6d67c2@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=alex.bennee@linaro.org \
    --cc=andrew.jones@linux.dev \
    --cc=ardb@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=darren@os.amperecomputing.com \
    --cc=david@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=gshan@redhat.com \
    --cc=gustavo.romero@linaro.org \
    --cc=harshpb@linux.ibm.com \
    --cc=ilkka@os.amperecomputing.com \
    --cc=imammedo@redhat.com \
    --cc=jean-philippe@linaro.org \
    --cc=jiakernel2@gmail.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=karl.heubaum@oracle.com \
    --cc=linux@armlinux.org.uk \
    --cc=linuxarm@huawei.com \
    --cc=lixianglai@loongson.cn \
    --cc=lpieralisi@kernel.org \
    --cc=maobibo@loongson.cn \
    --cc=maz@kernel.org \
    --cc=miguel.luis@oracle.com \
    --cc=mst@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=rafael@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=salil.mehta@huawei.com \
    --cc=salil.mehta@opnsrc.net \
    --cc=shahuang@redhat.com \
    --cc=vishnu@os.amperecomputing.com \
    --cc=wangxiongfeng2@huawei.com \
    --cc=wangyanan55@huawei.com \
    --cc=will@kernel.org \
    --cc=zhao1.liu@intel.com \
    --cc=zhukeqian1@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).