From nobody Sat Nov 23 23:21:56 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1730629597; cv=none; d=zohomail.com; s=zohoarc; b=mNvZr0WongbX4ItRkvSQ6Ftp4G3gar4yWHeUUAvfLGQTM+fHgB3X216cgNyM/4tr1pbGrFZ9vC/d4RveWlCLEQ4kB2lIf0y7/xD5mkTb8yWM/aN9JmOvIl0sx6bHPUHpF2APBo532jzxzuGBwospD1B7kNiVxfuKiEYjeM+WRiQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1730629597; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Sender:Subject:Subject:To:To:Message-Id; bh=WAKLr6Xe8L7POCW3jEVCqHDeXsUosEFvkZ5nrAL6PBA=; b=gWTXStVJo+trNIiy/FRbgy1A0RI2PBOuzczdU6HT5kpTpTpek4+lAGPp1535zridIRYRz6+15O74Pu2qtEON84JacMFMl/KD2OoF2zTDvB8eFMM7rxQxGgbaOfplJ9j1CfSoNhDhs3vU+244IfCFc0+HBP0q+7hoZZpDdiMC9lM= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1730629597285180.3396914455334; Sun, 3 Nov 2024 02:26:37 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7Xnu-0006oo-2H; Sun, 03 Nov 2024 05:25:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t7Xnr-0006nx-9Q; Sun, 03 Nov 2024 05:25:51 -0500 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t7Xnp-0005gQ-J5; Sun, 03 Nov 2024 05:25:51 -0500 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Xh9fM5ZkGz6K6JX; Sun, 3 Nov 2024 18:23:07 +0800 (CST) Received: from frapeml500007.china.huawei.com (unknown [7.182.85.172]) by mail.maildlp.com (Postfix) with ESMTPS id 1A8D0140C98; Sun, 3 Nov 2024 18:25:45 +0800 (CST) Received: from 00293818-MRGF.huawei.com (10.48.154.43) by frapeml500007.china.huawei.com (7.182.85.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sun, 3 Nov 2024 11:25:26 +0100 To: , , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH V3 1/5] hw/acpi: Make CPUs ACPI `presence` conditional during vCPU hot-unplug Date: Sun, 3 Nov 2024 10:24:15 +0000 Message-ID: <20241103102419.202225-2-salil.mehta@huawei.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20241103102419.202225-1-salil.mehta@huawei.com> References: <20241103102419.202225-1-salil.mehta@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.48.154.43] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To frapeml500007.china.huawei.com (7.182.85.172) Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=185.176.79.56; envelope-from=salil.mehta@huawei.com; helo=frasgout.his.huawei.com X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Salil Mehta From: Salil Mehta via Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZM-MESSAGEID: 1730629599134116600 On most architectures, during vCPU hot-plug and hot-unplug actions, the firmware or VMM/QEMU can update the OS on vCPU status by toggling the ACPI method `_STA.Present` bit. However, certain CPU architectures prohibit [1] modifications to a CPU=E2=80=99s `presence` status after the k= ernel has booted. This limitation [2][3] exists because many per-CPU components, such as interrupt controllers and various per-CPU features tightly integrated with CPUs, may not support reconfiguration once the kernel is initialized. Often, these components cannot be powered down, as they may belong to an `always-on` power domain. As a result, some architectures require all CPUs to remain `_STA.Present` after system initialization. Therefore, it is essential to mirror the exact QOM vCPU status through ACPI for the Guest kernel. For this, we should determine=E2=80=94via architecture-specific code[4]=E2=80=94whether vCPUs must always remain pres= ent and whether the associated `AcpiCpuStatus::cpu` object should remain valid, even following a vCPU hot-unplug operation. References: [1] Check comment 5 in the bugzilla entry Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3D4481#c5 [2] KVMForum 2023 Presentation: Challenges Revisited in Supporting Virt CPU= Hotplug on architectures that don=E2=80=99t Support CPU Hotplug (like ARM64) a. Kernel Link: https://kvm-forum.qemu.org/2023/KVM-forum-cpu-hotplug_7= OJ1YyJ.pdf b. Qemu Link: https://kvm-forum.qemu.org/2023/Challenges_Revisited_in_= Supporting_Virt_CPU_Hotplug_-__ii0iNb3.pdf [3] KVMForum 2020 Presentation: Challenges in Supporting Virtual CPU Hotplu= g on SoC Based Systems (like ARM64) Link: https://kvmforum2020.sched.com/event/eE4m [4] Example implementation of architecture-specific CPU persistence hook Link: https://github.com/salil-mehta/qemu/commit/c0b416b11e5af6505e5588= 66f0eb6c9f3709173e Signed-off-by: Salil Mehta --- hw/acpi/cpu.c | 15 ++++++++++++++- include/hw/core/cpu.h | 1 + 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c index 5cb60ca8bc..9b03b4292e 100644 --- a/hw/acpi/cpu.c +++ b/hw/acpi/cpu.c @@ -233,6 +233,17 @@ void cpu_hotplug_hw_init(MemoryRegion *as, Object *own= er, memory_region_add_subregion(as, base_addr, &state->ctrl_reg); } =20 +static bool should_remain_acpi_present(DeviceState *dev) +{ + CPUClass *k =3D CPU_GET_CLASS(dev); + /* + * A system may contain CPUs that are always present on one die, NUMA = node, + * or socket, yet may be non-present on another simultaneously. Check = from + * architecture specific code. + */ + return k->cpu_persistent_status && k->cpu_persistent_status(CPU(dev)); +} + static AcpiCpuStatus *get_cpu_status(CPUHotplugState *cpu_st, DeviceState = *dev) { CPUClass *k =3D CPU_GET_CLASS(dev); @@ -289,7 +300,9 @@ void acpi_cpu_unplug_cb(CPUHotplugState *cpu_st, return; } =20 - cdev->cpu =3D NULL; + if (!should_remain_acpi_present(dev)) { + cdev->cpu =3D NULL; + } } =20 static const VMStateDescription vmstate_cpuhp_sts =3D { diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h index c3ca0babcb..e7de77dc6d 100644 --- a/include/hw/core/cpu.h +++ b/include/hw/core/cpu.h @@ -158,6 +158,7 @@ struct CPUClass { void (*dump_state)(CPUState *cpu, FILE *, int flags); void (*query_cpu_fast)(CPUState *cpu, CpuInfoFast *value); int64_t (*get_arch_id)(CPUState *cpu); + bool (*cpu_persistent_status)(CPUState *cpu); void (*set_pc)(CPUState *cpu, vaddr value); vaddr (*get_pc)(CPUState *cpu); int (*gdb_read_register)(CPUState *cpu, GByteArray *buf, int reg); --=20 2.34.1