On Thu, 31 Mar 2022 11:47:26 -0700 (PDT) Ilkka Koskinen ilkka@os.amperecomputing.com wrote:

Hi everyone,

On Tue, 22 Mar 2022, Jonathan Cameron via Linaro-open-discussions wrote:

...

Hi All,

A quick set of notes on the discussion on vCPU hotplug.

Great to have Ed join the discussion. If we are going to have further calls on this topic we may want to move the time to be more friendly for the US.

Current status

• ACPI spec change via code first route approved.
• Kernel patches being reworked / rebased by ARM. Expected to be sent

out in 5.19 cycle.

• QEMU patches being updated by Huawei. Will do at least some light testing

and then push out a public git tree so that others can test - will aim to do this so it aligns with kernel code availability.

• Ed (Ampere) gave an update to say they are interested in pushing this

forwards ASAP and have customer / OS vendor engagement which will be very useful in moving towards a complete solution, particularly ensuring good test coverage etc.

Noted that current QEMU patches may not cover all corner cases, for example live migration of VMs that have vCPUs hotplugged. Might 'just work' but we haven't tested it yet so probably not.

Given we didn't really add anything on DOE / SPDM over previous calls, I don't plan to send out anything on that topic this time.

Thanks to Joyce for hosting the call. If I noted down anything wrong, or incomplete let the list know.

Jonathan

Linaro-open-discussions mailing list -- linaro-open-discussions@op-lists.linaro.org https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home

Thanks for the great meeting and the update! As Ed mentioned (and you wrote above), we're interested in joining the vCPU Hotplug development.

Hi Ilkka

Great to have you on board for this.

Status wise, on QEMU side we have the new interface up and running (it was a whole 2 lines of code once we'd dealt with some rebasing related issues).

Rather more changes were needed to make it work sensibly on top of Gavin Shan's QEMU topology configuration patch set. https://lore.kernel.org/qemu-devel/20220403145953.10522-1-gshan@redhat.com/ The code going through some light internal review before we put it up somewhere public. Note it's definitely not production quality code but it is somewhere to start from. Given Easter related vacations I doubt we'll get enough eyes on it until next week.

We were thrown briefly by the fact there is a recently added apcica/actbl2.h entry for MADT_ONLINE_CAPABLE but it's a different bit. Seems x86 folk wanted something similar last year. We'll have to do something ugly in ACPICA to mangle the name for the new bit to avoid that collision. Lorenzo, I'm assuming the ACPCIA one line patch to add that define is something the ARM team will deal with?

There are some known limitations though that we'll need to sort out before upstreaming the QEMU support. One of which is SVE currently breaks things. Plenty of time though as kernel needs to be upstream first anyway.

Testing wise we are using QEMU on top of QEMU so we can poke corners of the architecture don't have hardware for (e.g. SVE :). Even on a rubbish x86 desktop it's not that slow :)

Lorenzo, any update on kernel side of things or expected time scale for more information?

Obviously we have some hacked patches based on Salil's original proposal that sanity check the QEMU side of things but I suspect the final version will look rather different :)

One question on the spec change for Lorenzo. It's not entirely clear but I think we should not be using _MAT when 'hotplugging' the vCPUs? For now the QEMU code provides the relevant entries anyway but it would be nice to drop that if not necessary (it's not a huge amount of code or complexity though so not a big thing either way).

Thanks and an early happy Easter to those celebrating on Sunday.

Jonathan

Br, Ilkka