On Mon, 13 Mar 2023 15:50:52 +0000
James Morse [off-list ref] wrote:

Hi Jonathan,

On 07/03/2023 12:00, Jonathan Cameron wrote:

quoted

On Fri,  3 Feb 2023 13:50:11 +0000
James Morse [off-list ref] wrote:  

quoted

quoted

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.  

quoted

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.

quoted

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!

quoted

_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

From a quick glance that looks good to me.

It'll appear in the v1 of the series once the kernel and qemu bits are all lined up again.

We'll also need to kick off the spec change with a code-first proposal.
I think current standard way to do that is a bugzilla entry in EDK2 repo 
https://bugzilla.tianocore.org/buglist.cgi?component=Specification%20Update&product=EDK2%20Code%20First&resolution=---
and the get someone in ASWG to create equivalent tracking issue in mantis.

Great if you already have that in hand via relevant ARM folks.

Jonathan

Thanks,

James

quoted

_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