On Fri, Oct 29, 2021 at 12:04:52PM +0100, Jonathan Cameron wrote:
On Thu, 28 Oct 2021 14:31:57 +0100 Lorenzo Pieralisi lorenzo.pieralisi@arm.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 linaro-open-discussions@op-lists.linaro.org wrote:
Hi all,
The monthly meeting will happen next Monday (Oct 25th), please let me know if you have any topics to cover.
Thanks, Jammy
Hi All,
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:
https://bugzilla.tianocore.org/show_bug.cgi?id=3706
I believe we should coordinate effort around bits and pieces that we need to upstream to enable it.
Thanks, Lorenzo
Hi Lorenzo,
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").
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 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).
Lorenzo
Jonathan
Thanks,
Jonathan
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