Hi all,
The monthly meeting will happen next Monday (Oct 25th), please let me know if you have any topics to cover.
Thanks, Jammy
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.
Thanks,
Jonathan
I waited about ten minutes, and I was the only one in the call. So I think there was nothing to discuss this time. Talk to you again in a month.
On Mon, 25 Oct 2021 at 18:24, Jonathan Cameron Jonathan.Cameron@huawei.com 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.
Thanks,
Jonathan
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
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
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? 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.
Agreed that we need to coordinate efforts to get this enabled upstream.
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
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
On Mon, 1 Nov 2021 10:44:10 +0000 Lorenzo Pieralisi lorenzo.pieralisi@arm.com 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 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").
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).
Good luck.
Side note, the link to the mantis ticket form the bugzilla is broken (has a bonus 'v' on the end I think...)
Jonathan
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
On Mon, Nov 01, 2021 at 02:32:34PM +0000, Jonathan Cameron wrote:
[...]
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.
Updated. Added as a clarification in the MADT GICC paragraph rather than a flag.
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).
Good luck.
Fingers crossed - we should be done and soon ready to upstream.
It would be good to nudge Kubernetes folks (but Salil should know already) to get their opinion on the resulting flow.
The main difference with his initial kernel work is that now all cpus are present and possible, I don't see any issue with that but we can check.
Side note, the link to the mantis ticket form the bugzilla is broken (has a bonus 'v' on the end I think...)
Commented on the entry to fix it, thanks.
Lorenzo
Jonathan
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
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.
FYI, I can't make the call this Monday 22nd so it would be best to reschedule it please if possible, from Tuesday onwards.
Thanks, Lorenzo
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
On Fri, 19 Nov 2021 10:31:44 +0000 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.
FYI, I can't make the call this Monday 22nd so it would be best to reschedule it please if possible, from Tuesday onwards.
Do we have any agenda items yet?
I don't have anything urgent to raise.
Jonathan
Thanks, Lorenzo
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
It looks like everything goes well recently. Zhangfei and I were on the call for around ten minutes, and nobody else showed up. Besides, we may need to cancel the call in December for Christmas Holiday. Please let me know if we need to arrange extra call before that.
On Fri, 19 Nov 2021 at 18:53, Jonathan Cameron via Linaro-open-discussions < linaro-open-discussions@op-lists.linaro.org> wrote:
On Fri, 19 Nov 2021 10:31:44 +0000 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.
FYI, I can't make the call this Monday 22nd so it would be best to reschedule it please if possible, from Tuesday onwards.
Do we have any agenda items yet?
I don't have anything urgent to raise.
Jonathan
Thanks, Lorenzo
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
-- 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
linaro-open-discussions@op-lists.linaro.org
-
Jammy Zhou -
Jonathan Cameron -
Lorenzo Pieralisi