Linaro Open Discussions monthly meeting
Tuesday 23 Aug 2022 ⋅ 22:00 – 23:00
Hong Kong Standard Time
Location
https://linaro-org.zoom.us/j/95682500341https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9568250…
Joyce QI 邀请您参加预先安排的 Zoom 会议。
加入 Zoom 会议
https://linaro-org.zoom.us/j/95682500341
会议号:956 8250 0341
手机一键拨号
+16699009128,,95682500341# 美国 (San Jose)
+13462487799,,95682500341# 美国 (Houston)
根据您的位置拨号
+1 669 900 9128 美国 (San Jose)
+1 346 248 7799 美国 (Houston)
+1 253 215 8782 美国 (Tacoma)
+1 646 558 8656 美国 (New York)
+1 301 715 8592 美国 (Washington DC)
+1 312 626 6799 美国 (Chicago)
888 788 0099 美国 免费
877 853 5247 美国 免费
会议号:956 8250 0341
查找本地号码:https://linaro-org.zoom.us/u/ady2J9Zn7t
Guests
lorenzo.pieralisi(a)arm.com
ilkka(a)os.amperecomputing.com
jonathan.cameron(a)huawei.com
salil.mehta(a)huawei.com
james.morse(a)arm.com
Mike Holmes
linaro-open-discussions(a)op-lists.linaro.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv…
Reply for linaro-open-discussions(a)op-lists.linaro.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=Mjg1MjNrNWtiMWxv…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee of the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organiser, be added to the guest list, invite others regardless of
their own invitation status or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi folks,
I would like to take advantage of the upcoming call on tuesday to
resume the virt CPU hotplug topic and sync-up on that.
It would probably be great if we can make the time more US friendly,
given that there are folks who want to join from the US but I understand
it then becomes problematic for other people to join.
Please let me know if we can have a meeting on tuesday and at
what time.
Thanks,
Lorenzo
Hi Jonathon,Lorenzo,
Do we have some topic to discuss for the Linaro-open-disscussions next week?
Thanks:)
Joyce
> 在 2022年4月14日,上午8:00,linaro-open-discussions-request@op-lists.linaro.org 写道:
>
> Send Linaro-open-discussions mailing list submissions to
> linaro-open-discussions(a)op-lists.linaro.org
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> linaro-open-discussions-request(a)op-lists.linaro.org
>
> You can reach the person managing the list at
> linaro-open-discussions-owner(a)op-lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linaro-open-discussions digest..."
>
> Today's Topics:
>
> 1. Re: LOD Call notes: 22 March 2022 - vCPU Hotplug Update
> (Jonathan Cameron)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Apr 2022 19:17:32 +0100
> From: Jonathan Cameron <Jonathan.Cameron(a)Huawei.com>
> Subject: [Linaro-open-discussions] Re: LOD Call notes: 22 March 2022 -
> vCPU Hotplug Update
> To: Ilkka Koskinen <ilkka(a)os.amperecomputing.com>
> Cc: linaro-open-discussions(a)op-lists.linaro.org
> Message-ID: <20220413191732.00000e4e(a)Huawei.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> On Thu, 31 Mar 2022 11:47:26 -0700 (PDT)
> Ilkka Koskinen <ilkka(a)os.amperecomputing.com> wrote:
>
>> Hi everyone,
>>
>> On Tue, 22 Mar 2022, Jonathan Cameron via Linaro-open-discussions wrote:
>>> Hi All,
>>>
>>> A quick set of notes on the discussion on vCPU hotplug.
>>>
>>> Great to have Ed join the discussion. If we are going to
>>> have further calls on this topic we may want to move the time to be
>>> more friendly for the US.
>>>
>>> Current status
>>> * ACPI spec change via code first route approved.
>>> * Kernel patches being reworked / rebased by ARM. Expected to be sent
>>> out in 5.19 cycle.
>>> * QEMU patches being updated by Huawei. Will do at least some light testing
>>> and then push out a public git tree so that others can test - will aim
>>> to do this so it aligns with kernel code availability.
>>> * Ed (Ampere) gave an update to say they are interested in pushing this
>>> forwards ASAP and have customer / OS vendor engagement which will be
>>> very useful in moving towards a complete solution, particularly ensuring
>>> good test coverage etc.
>>>
>>> Noted that current QEMU patches may not cover all corner cases, for example
>>> live migration of VMs that have vCPUs hotplugged. Might 'just work'
>>> but we haven't tested it yet so probably not.
>>>
>>> Given we didn't really add anything on DOE / SPDM over previous calls,
>>> I don't plan to send out anything on that topic this time.
>>>
>>> Thanks to Joyce for hosting the call. If I noted down anything wrong,
>>> or incomplete let the list know.
>>>
>>> Jonathan
>>> --
>>> Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org
>>> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
>>
>> Thanks for the great meeting and the update! As Ed mentioned (and you
>> wrote above), we're interested in joining the vCPU Hotplug development.
>
> Hi Ilkka
>
> Great to have you on board for this.
>
> Status wise, on QEMU side we have the new interface up and running
> (it was a whole 2 lines of code once we'd dealt with some rebasing related issues).
>
> Rather more changes were needed to make it work sensibly on top of Gavin Shan's
> QEMU topology configuration patch set.
> https://lore.kernel.org/qemu-devel/20220403145953.10522-1-gshan@redhat.com/
> The code going through some light internal review before we put it up somewhere
> public. Note it's definitely not production quality code but it is somewhere
> to start from. Given Easter related vacations I doubt we'll get enough
> eyes on it until next week.
>
> We were thrown briefly by the fact there is a recently added
> apcica/actbl2.h entry for MADT_ONLINE_CAPABLE but it's a different bit.
> Seems x86 folk wanted something similar last year. We'll have to do something
> ugly in ACPICA to mangle the name for the new bit to avoid that collision.
> Lorenzo, I'm assuming the ACPCIA one line patch to add that define is
> something the ARM team will deal with?
>
> There are some known limitations though that we'll need to sort out before
> upstreaming the QEMU support. One of which is SVE currently breaks things.
> Plenty of time though as kernel needs to be upstream first anyway.
>
> Testing wise we are using QEMU on top of QEMU so we can poke corners of the
> architecture don't have hardware for (e.g. SVE :). Even on a rubbish x86
> desktop it's not that slow :)
>
> Lorenzo, any update on kernel side of things or expected time scale for
> more information?
>
> Obviously we have some hacked patches based on Salil's original proposal
> that sanity check the QEMU side of things but I suspect the final version
> will look rather different :)
>
> One question on the spec change for Lorenzo. It's not entirely clear
> but I think we should not be using _MAT when 'hotplugging' the vCPUs?
> For now the QEMU code provides the relevant entries anyway but
> it would be nice to drop that if not necessary (it's not a huge
> amount of code or complexity though so not a big thing either way).
>
> Thanks and an early happy Easter to those celebrating on Sunday.
>
> Jonathan
>
>>
>> Br, Ilkka
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Linaro-open-discussions mailing list -- linaro-open-discussions(a)op-lists.linaro.org
> To unsubscribe send an email to linaro-open-discussions-leave(a)op-lists.linaro.org
>
>
> ------------------------------
>
> End of Linaro-open-discussions Digest, Vol 19, Issue 1
> ******************************************************
Hi,
OP-TEE Contributions (LOC) monthly meeting is planned for Thursday April 28
@17.00 (UTC + 2).
We have following on the agenda
- Fault Mitigation patterns in OP-TEE - Jens Wiklander
If you have any more topics you'd like to discuss, please let us know and
we can schedule them.
Meeting details:
---------------
Date/time: April 28(a)17.00 (UTC + 2)
https://everytimezone.com/s/700b9d66
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Regards,
Ruchika on behalf of the Linaro OP-TEE team
Hi,
This is a combination of yangyicong and my notes. If we missed anything please
point it out.
RMR:
- (Shameer) Request to look at Patch 4 as some changes from earlier versions. Warning fix for next version.
- Lorenzo will check with Robin.
- Need to ask Joerg to pull the series.
vCPU HP.
- https://gitlab.com/jic23/qemu/-/commits/vcpu-poc-1
- Kernel Patches - hopefully posted soon. Not Lorenzo as not available for a few months.
- _MAT needed or not.
SPDM
- Random discussion of the difficulty of debugging the rather complex exchanges. Nothing worth
noting.
Scheduler:
Yangyicong's slides provide a good summary of the question.
- Observed that any topology based estimate is going to be challenging!
- Vincent - set migration cost per sched domain level?
- Dietmar - workloads weren't clear in original thread.
Question of taskhot or new Idle Balance as relevant to workload.
Tighter description of what is going on in the benchmarks needed.
- Vincent - Uarch + cache etc relevant.
- Hesham - potentially user perf counters to get some more info.
Takeways
1. Need to figure out the underlying reason of the performance variation of certain benchmark:
If it's because of task hotness or newidle_balance(), etc.
2. Effect may related to the micro-arch, cache, and task's states. Also can be tuned according
to the cpu numbers and scheduler domain levels.
3. Can be get from some firmware reports, to avoid the long time measurement in booting.
4. May be possible to calibrate during the boot time, but narrow the scope of measured CPUs
and test time. This won't take long, but is susceptible to noise from other sources.
5. Hardware counters or profilings help understand what is going on, but unlikely to be
consistently available for use in the loop.
6. Maybe make migration cost per sched domain on implementation.
Thanks,
Jonathan