From: James Morse <james.morse@arm.com> To: Jonathan Cameron <Jonathan.Cameron@Huawei.com> Cc: linux-pm@vger.kernel.org, loongarch@lists.linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, Marc Zyngier <maz@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, Dave Hansen <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Huacai Chen <chenhuacai@kernel.org>, Suzuki K Poulose <suzuki.poulose@arm.com>, Oliver Upton <oliver.upton@linux.dev>, Len Brown <lenb@kernel.org>, Rafael Wysocki <rafael@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Salil Mehta <salil.mehta@huawei.com>, Russell King <linux@armlinux.org.uk>, Jean-Philippe Brucker <jean-philippe@linaro.org>, kangkang.shen@futurewei.com Subject: Re: [RFC PATCH 00/32] ACPI/arm64: add support for virtual cpuhotplug Date: Mon, 13 Mar 2023 15:50:52 +0000 [thread overview] Message-ID: <1f21673e-e5e6-a158-94a4-6ae6724c1f93@arm.com> (raw) In-Reply-To: <20230307120050.000032f1@Huawei.com> Hi Jonathan, On 07/03/2023 12:00, Jonathan Cameron wrote: > On Fri, 3 Feb 2023 13:50:11 +0000 > James Morse <james.morse@arm.com> wrote: >> 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 as physical hotplug, and firmware can cause the CPU to be registered some >> time later, allowing it to be brought online. > As we discussed on an LOD call a while back, I think that we need some path to > find out if the guest supports vCPU HP or not so that info can be queried by > an orchestrator / libvirt etc. In general the entity responsible for allocating > extra vCPUs may not know what support the VM has for this feature. I agree. For arm64 this is going to be important if/when there are machines that do physical hotplug of CPUs too. > There are various ways we could get this information into the VMM. > My immediate thought is to use one of the ACPI interfaces that lets us write > AML that can set an emulated register. A query to the VMM can check if this > register is set. > > So options. > > _OSI() - Deprecated on ARM64 so lets not use that ;) News to me, I've only just discovered it! > _OSC() - Could add a bit to Table 6.13 Platform-Wide Capabilites in ACPI 6.5 spec. > Given x86 has a similar online capable bit perhaps this is the best option > though it is the one that requires a formal code first proposal to ASWG. I've had a go at writing this one: https://gitlab.arm.com/linux-arm/linux-jm/-/commit/220b0d8b0261d7467c8705e6f614d57325798859 It'll appear in the v1 of the series once the kernel and qemu bits are all lined up again. Thanks, James > _OSC() - Could add a new UUID and put it under a suitable device - maybe all CPUs? > You could definitely argue this feature is an operating system property. > _DSM() - Similar to OSC but always under a device. > Whilst can be used for this I'm not sure it really matches intended usecase. > > Assuming everyone agrees this bit of introspection is useful, > Rafael / other ACPI specialists: Any suggestions on how best to do this?
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com> To: Jonathan Cameron <Jonathan.Cameron@Huawei.com> Cc: linux-pm@vger.kernel.org, loongarch@lists.linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, Marc Zyngier <maz@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>, Dave Hansen <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Huacai Chen <chenhuacai@kernel.org>, Suzuki K Poulose <suzuki.poulose@arm.com>, Oliver Upton <oliver.upton@linux.dev>, Len Brown <lenb@kernel.org>, Rafael Wysocki <rafael@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Salil Mehta <salil.mehta@huawei.com>, Russell King <linux@armlinux.org.uk>, Jean-Philippe Brucker <jean-philippe@linaro.org>, kangkang.shen@futurewei.com Subject: Re: [RFC PATCH 00/32] ACPI/arm64: add support for virtual cpuhotplug Date: Mon, 13 Mar 2023 15:50:52 +0000 [thread overview] Message-ID: <1f21673e-e5e6-a158-94a4-6ae6724c1f93@arm.com> (raw) In-Reply-To: <20230307120050.000032f1@Huawei.com> Hi Jonathan, On 07/03/2023 12:00, Jonathan Cameron wrote: > On Fri, 3 Feb 2023 13:50:11 +0000 > James Morse <james.morse@arm.com> wrote: >> 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 as physical hotplug, and firmware can cause the CPU to be registered some >> time later, allowing it to be brought online. > As we discussed on an LOD call a while back, I think that we need some path to > find out if the guest supports vCPU HP or not so that info can be queried by > an orchestrator / libvirt etc. In general the entity responsible for allocating > extra vCPUs may not know what support the VM has for this feature. I agree. For arm64 this is going to be important if/when there are machines that do physical hotplug of CPUs too. > There are various ways we could get this information into the VMM. > My immediate thought is to use one of the ACPI interfaces that lets us write > AML that can set an emulated register. A query to the VMM can check if this > register is set. > > So options. > > _OSI() - Deprecated on ARM64 so lets not use that ;) News to me, I've only just discovered it! > _OSC() - Could add a bit to Table 6.13 Platform-Wide Capabilites in ACPI 6.5 spec. > Given x86 has a similar online capable bit perhaps this is the best option > though it is the one that requires a formal code first proposal to ASWG. I've had a go at writing this one: https://gitlab.arm.com/linux-arm/linux-jm/-/commit/220b0d8b0261d7467c8705e6f614d57325798859 It'll appear in the v1 of the series once the kernel and qemu bits are all lined up again. Thanks, James > _OSC() - Could add a new UUID and put it under a suitable device - maybe all CPUs? > You could definitely argue this feature is an operating system property. > _DSM() - Similar to OSC but always under a device. > Whilst can be used for this I'm not sure it really matches intended usecase. > > Assuming everyone agrees this bit of introspection is useful, > Rafael / other ACPI specialists: Any suggestions on how best to do this? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-13 15:51 UTC|newest] Thread overview: 164+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-03 13:50 [RFC PATCH 00/32] ACPI/arm64: add support for virtual cpuhotplug James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 01/32] ia64: Fix build error due to switch case label appearing next to declaration James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 02/32] ACPI: Move ACPI_HOTPLUG_CPU to be enabled per architecture James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-08-30 18:31 ` Russell King (Oracle) 2023-08-30 18:31 ` Russell King (Oracle) 2023-02-03 13:50 ` [RFC PATCH 03/32] drivers: base: Use present CPUs in GENERIC_CPU_DEVICES James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 04/32] drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 05/32] drivers: base: Move cpu_dev_init() after node_dev_init() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 06/32] arm64: setup: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 07/32] ia64/topology: Switch over to GENERIC_CPU_DEVICES James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 08/32] x86/topology: " James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 09/32] LoongArch: " James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 10/32] arch_topology: Make register_cpu_capacity_sysctl() tolerant to late CPUs James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 11/32] ACPI: processor: Add support for processors described as container packages James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 12/32] ACPI: processor: Register CPUs that are online, but not described in the DSDT James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 13/32] ACPI: processor: Register all CPUs from acpi_processor_get_info() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 14/32] ACPI: Rename ACPI_HOTPLUG_CPU to include 'present' James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 15/32] ACPI: Move acpi_bus_trim_one() before acpi_scan_hot_remove() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 16/32] ACPI: Rename acpi_processor_hotadd_init and remove pre-processor guards James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 17/32] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 18/32] ACPI: Check _STA present bit before making CPUs not present James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 19/32] ACPI: Warn when the present bit changes but the feature is not enabled James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 20/32] drivers: base: Implement weak arch_unregister_cpu() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 21/32] LoongArch: Use the __weak version of arch_unregister_cpu() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 22/32] arm64: acpi: Move get_cpu_for_acpi_id() to a header James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 23/32] ACPICA: Add new MADT GICC flags fields [code first?] James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 24/32] arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 25/32] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 26/32] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 27/32] arm64: psci: Ignore DENIED CPUs James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 28/32] ACPI: add support to register CPUs based on the _STA enabled bit James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 29/32] KVM: arm64: Pass hypercalls to userspace James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 21:08 ` Oliver Upton 2023-02-03 21:08 ` Oliver Upton 2023-02-03 21:08 ` Oliver Upton 2023-02-07 17:50 ` James Morse 2023-02-07 17:50 ` James Morse 2023-02-07 17:50 ` James Morse 2023-02-08 9:02 ` Marc Zyngier 2023-02-08 9:02 ` Marc Zyngier 2023-02-05 10:12 ` Marc Zyngier 2023-02-05 10:12 ` Marc Zyngier 2023-02-06 10:10 ` Suzuki K Poulose 2023-02-06 10:10 ` Suzuki K Poulose 2023-02-06 10:10 ` Suzuki K Poulose 2023-02-06 12:31 ` Marc Zyngier 2023-02-06 12:31 ` Marc Zyngier 2023-02-07 9:41 ` Suzuki K Poulose 2023-02-07 9:41 ` Suzuki K Poulose 2023-02-07 9:41 ` Suzuki K Poulose 2023-02-07 11:23 ` Marc Zyngier 2023-02-07 11:23 ` Marc Zyngier 2023-02-07 12:46 ` Suzuki K Poulose 2023-02-07 12:46 ` Suzuki K Poulose 2023-02-07 12:46 ` Suzuki K Poulose 2023-02-06 17:19 ` Oliver Upton 2023-02-06 17:19 ` Oliver Upton 2023-02-06 17:19 ` Oliver Upton 2023-02-07 17:50 ` James Morse 2023-02-07 17:50 ` James Morse 2023-02-07 17:50 ` James Morse 2023-02-08 8:40 ` Marc Zyngier 2023-02-08 8:40 ` Marc Zyngier 2023-02-08 14:25 ` Marc Zyngier 2023-02-08 14:25 ` Marc Zyngier 2023-02-11 1:44 ` Oliver Upton 2023-02-11 1:44 ` Oliver Upton 2023-02-03 13:50 ` [RFC PATCH 30/32] KVM: arm64: Pass PSCI calls " James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-05-23 9:32 ` Salil Mehta 2023-05-23 9:32 ` Salil Mehta 2023-05-23 9:32 ` Salil Mehta 2023-09-12 17:01 ` James Morse 2023-09-12 17:01 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 31/32] arm64: document virtual CPU hotplug's expectations James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` [RFC PATCH 32/32] cpumask: Add enabled cpumask for present CPUs that can be brought online James Morse 2023-02-03 13:50 ` James Morse 2023-02-03 13:50 ` James Morse 2023-03-07 12:00 ` [RFC PATCH 00/32] ACPI/arm64: add support for virtual cpuhotplug Jonathan Cameron 2023-03-07 12:00 ` Jonathan Cameron 2023-03-07 12:00 ` Jonathan Cameron 2023-03-13 15:50 ` James Morse [this message] 2023-03-13 15:50 ` James Morse 2023-03-14 11:02 ` Jonathan Cameron 2023-03-14 11:02 ` Jonathan Cameron 2023-03-14 11:02 ` Jonathan Cameron 2023-03-29 2:35 ` Gavin Shan 2023-03-29 2:35 ` Gavin Shan 2023-03-29 2:35 ` Gavin Shan 2023-09-12 17:01 ` James Morse 2023-09-12 17:01 ` James Morse 2023-09-12 22:38 ` Gavin Shan 2023-09-12 22:38 ` Gavin Shan 2023-09-13 15:28 ` Russell King (Oracle) 2023-09-13 15:28 ` Russell King (Oracle) 2023-03-29 5:52 ` Shaoqin Huang 2023-03-29 5:52 ` Shaoqin Huang 2023-03-29 5:52 ` Shaoqin Huang 2023-04-03 6:25 ` Gavin Shan 2023-04-03 6:25 ` Gavin Shan 2023-04-03 6:25 ` Gavin Shan
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=1f21673e-e5e6-a158-94a4-6ae6724c1f93@arm.com \ --to=james.morse@arm.com \ --cc=Jonathan.Cameron@Huawei.com \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=chenhuacai@kernel.org \ --cc=dave.hansen@linux.intel.com \ --cc=hpa@zytor.com \ --cc=jean-philippe@linaro.org \ --cc=kangkang.shen@futurewei.com \ --cc=kernel@xen0n.name \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.linux.dev \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=loongarch@lists.linux.dev \ --cc=lpieralisi@kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=mingo@redhat.com \ --cc=oliver.upton@linux.dev \ --cc=rafael@kernel.org \ --cc=salil.mehta@huawei.com \ --cc=sudeep.holla@arm.com \ --cc=suzuki.poulose@arm.com \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ --cc=x86@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.