On Mon, 1 Nov 2021 10:44:10 +0000 Lorenzo Pieralisi firstname.lastname@example.org wrote:
On Fri, Oct 29, 2021 at 12:04:52PM +0100, Jonathan Cameron wrote:
On Thu, 28 Oct 2021 14:31:57 +0100 Lorenzo Pieralisi email@example.com wrote:
On Mon, Oct 25, 2021 at 11:24:06AM +0100, Jonathan Cameron via Linaro-open-discussions wrote:
On Tue, 19 Oct 2021 08:40:09 +0800 Jammy Zhou via Linaro-open-discussions firstname.lastname@example.org wrote:
The monthly meeting will happen next Monday (Oct 25th), please let me know if you have any topics to cover.
Obviously a bit late, but just for clarity, no topics from our side this month. Not clear yet what will be ready for discussion next month, but lets put the date in the diary and discuss an agenda nearer the time.
As promised, the Code-first ECR to enable virtual CPU hotplug was published:
I believe we should coordinate effort around bits and pieces that we need to upstream to enable it.
Thanks for the link. A few questions from a quick read. It's been a while so I may well have forgotten how the flows work...
The online capable bit is documented as being reserved and zero if Enabled is set. This seems to rule out using it for information on CPUs that are initially enabled but which we may want to later remove from a given VM?
The rationale behind this is:
- MADT is a static table and describes the static properties of a system. We want to rule out "ejecting" and therefore disabling a core that was marked as "enabled" in the MADT (for some use cases, ie kexec, this won't work at all, we don't rewrite static tables - they are...static) We would allow "disabling" a core that was disabled in the MADT and later (virtually) hotplugged in and therefore "enabled". The long and short of it is: we consider the enabled flag firmware policy, the online-capable flag gives us the backward compatibility we need (ie we consider possible even cores that aren't "enabled").
That all makes sense. I guess we just end up with systems that have queued up a bunch of ACPI events for just after initial boot to bring CPUs online.
If we compare with the SRAT entry for the equivalent memory case that explicitly does allow the enabled + hotplug case. I looked back at the memory hotplug series though and after much discussion seems conclusion was to just ignore that for arm64. I guess you may run into similar discussion around this one where people want the option to do something different with the information...
We could just enable a flow where such CPUs have to be enabled after boot, but that seems unnecessarily limiting.
What is the point in a non present bit that must always be zero? I assume this is about leaving space for a future physical hotplug but even so it seems unwise to drop in a field that must be zero. My inclination is don't define this bit until you need it - will be reserved 0 anyway so I'm not sure I see why it needs reserving.
Not-present is there to explain/clarify what "enabled" means, it is a clarification and not strictly necessary (I mean a clarification of sorts is needed in the spec anyway).
Agreed that a clarification is good but not necessarily this one.
Agreed that we need to coordinate efforts to get this enabled upstream.
Yes, let's get at least the online-capable/enabled changes in the specs (which is already proving to be interesting).
Side note, the link to the mantis ticket form the bugzilla is broken (has a bonus 'v' on the end I think...)
Linaro-open-discussions mailing list https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions