Hi James,
From: James Morse james.morse@arm.com Sent: Wednesday, June 7, 2023 11:00 AM
Hi Salil,
On 06/06/2023 15:49, Salil Mehta wrote:
From: James Morse james.morse@arm.com Sent: Tuesday, June 6, 2023 11:32 AM On 05/06/2023 11:26, Salil Mehta wrote:
Few questions related to new _OSC capabilities to negotiate the type of CPU hotplug(if any):
Q1: ACPI Standard Update: Do we have any Bugzilla-id for the change related to these new _OSC capabilities for the type of CPU hotplug support (i.e. Enabled/Present cpu)?
I don't think so. I was intending on this being code-first, as and when this is on the mailing list I'd poke the arm people that look after the ACPI stuff to do ... what ever is necessary.
Ok. When do you plan to send the 'RFC vN' with this _OSC change?
Once I can test it! How are the qemu changes going?
There is no point posting it without testing the changes Oliver proposed. I've done bits of that with the kvmtool version I shared, but no-one can test this thing end to end until the Qemu side of it is updateed to match.
Sure, but to be able to test Qemu patches one need your rebased version of the kernel. It is up to you whether you want to make it public or not. I did wait for that and then proceeded to create my own version of your 24th Feb 2023 Kernel changes.
Qemu Repo of the latest port (with Oliver's Uptons Patches): Link: https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port11052023.dev-1
Maybe, you can share a quick port of your kernel changes on gitlab so that people can get untied although I can share my own version of the port as well?
Q2: Have you intentionally omitted below function in the _OSC related kernel change shared in the repository [1]? bool acpi_processor_hotplug_enabled_supported(void)
Is this a build error? Or do you mean the lack of symmetry between handshaking support for the present and enabled bits?
There is no reason to forbid the enable/disabled support if firmware didn't do the handshake. The handshake is there for firmwares benefit, not the OS.
Do we always need to support any form of hotplug in kernel? Can we have below:
- Physical Hotplug Support
- Virtual Hotplug Support
The kernel can't tell these two apart. What we actually have is:
- Dynamically making a CPU present/not-present
- Dynamically making a CPU enabled/not-enabled
I see no reason not to enable (2) for all architectures, unless it turns out x86 has platforms which randomly change that bit assuming its ignored.
Agreed. So the check for both capabilities is a requirement. Could we have a case where Hotplug is not supported at all? Should we put a print in the kernel checking nothing else but these capabilities to detect any such random event in case hotplug is not supported at all?
- No Hotplug Support at all i.e. defaults to earlier kernel behavior without using any other information except capabilities from firmware/VMM
I'm not sure what your question is here. Why would you want to disable OS support for toggling the enabled bit? Blocking eject-requests is the only reason I can think of ... but there is no-way to do that today... why do we need one?
Sorry, I just meant to disable Hotplug support by detecting these _OSC capability Bits.
In contrast toggling the present bit is forbidden if the OS said it didn't support it, as the architecture code expects the machine to catch fire if you do this.
I do understand and we have an agreement on this. We are not manipulating _STA.PRES bit.
Q3: I am sure you would want to extend usage of these APIs in the acpi_processor.c as well to decide what kind of hotplug (if any) is enabled? Is code related to _OSC changes complete?
This is a leading question, but I can't tell what it is...
I haven't been able to test that _OSC code beyond what I can hack up with the FVP, so there are probably bits missing. Did you have something specific in mind?
Ok.
Why not use the 'osc_sb_hotplug_enabled_support_confirmed' flag to totally disable ANY kind of cpu hotplug at init time?
Because that would be extra work and extra code. Why is it needed?
I think I'm missing the use-case for linux not supporting this when the firmware does.
Just to make aware guest user about any such spurious hotplugging event when VMM/firmware does not supports it. Just a knob to enable/disable the hotplug behavior without relying on the ACPI _STA.{PRES, ENA} Bits?
I'm aware that the ACPI side of the cpu 'driver' is visible in sysfs when it shouldn't be, I plan to fix that once I have something I can test it with.
Ok. I will share the Qemu port today if you are waiting for that.
Great thanks. I haven't the time to look at this until at least the week after next.
Shared the link (see above)
Thanks Salil