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.
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: 1. Dynamically making a CPU present/not-present 2. 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.
- 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?
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.
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.
Thanks,
James