Hi Lorenzo,
> > -----Original Message-----
> > From: Linaro-open-discussions
> > [mailto:linaro-open-discussions-bounces@op-lists.linaro.org] On Behalf Of
> > Lorenzo Pieralisi via Linaro-open-discussions
> > Sent: 10 December 2020 09:13
> > To: Jonathan Cameron <jonathan.cameron(a)huawei.com>
> > Cc: linaro-open-discussions(a)op-lists.linaro.org
> > Subject: Re: [Linaro-open-discussions] Suggested Agenda / timings for
> Monday
> > 7 Dec call
> >
> > On Thu, Dec 03, 2020 at 01:40:55PM +0000, Jonathan Cameron wrote:
> >
> > [...]
> >
> > > RMR related topics - follow up on last call: Lorenzo Pieralisi (ARM) - 5 mins
Just a quick one on updated RMR spec publication. I see a revision E.a here,
https://developer.arm.com/documentation/den0049/latest/
This seems to have addressed all the things we discussed. Is this a final one officially?
If yes, I couldn't understand why the RMR node flags are at an offset 8, compared to
other nodes where the node specific data normally starts at offset 16.
Could you please check and let me know.
Thanks,
Shameer
Hi,
We have a LOC Monthly meeting scheduled for Thursday January 28th(a)16.00.
Please see the details below.
Regards,
Ruchika
---------- Forwarded message ---------
From: Joakim Bech via OP-TEE <op-tee(a)lists.trustedfirmware.org>
Date: Wed, 20 Jan 2021 at 21:38
Subject: Linaro OP-TEE Contributions meeting January 2021
To: OP-TEE TrustedFirmware <op-tee(a)lists.trustedfirmware.org>
Hi,
LOC monthly meeting is planned to take place Thursday January 28th(a)16.00
(UTC+1). This time we have two guest speakers, with two different topics.
- Clément Faure (NXP): HW crypto accelerator integration with crypto
framework in OP-TEE
- Sumit Garg (Linaro): TEE based Trusted Keys
This might take the whole meeting, but feel free to suggest topics you'd
like to
discuss otherwise (by replying to this email or write it directly in the
meeting
notes).
Meeting details:
---------------
Date/time: Thursday January 28th(a)16.00 (UTC+1)
https://everytimezone.com/s/c43ea835
Connection details: https://www.trustedfirmware.org/meetings/
Meeting notes: http://bit.ly/loc-notes
Project page: https://www.linaro.org/projects/#LOC
Regards,
Joakim on behalf of the Linaro OP-TEE team
Hi,
As Linaro Big Ideas aren't meant to hang around too long I wanted to do
a call to see if there was any interest in taking this further. Feedback
so far has been it look interesting and certainly looks useful from the
upstream point of view but generally members have other plans (rust-vmm
based solutions, kvmtool etc). From an engineering point of view I still
think there is use in having a slimmed down build of QEMU for ARM if
only to have something to benchmark against when developing the new
shiny tools.
So what do people think?
Worth having a call and firming up an initiative for voting on or clsong
the card due to lack of interest?
--
Alex Bennée
If we cannot make it for 8th, I agree with Jonathan that 22nd can be a
better option.
As to the time wise, I would keep it as it is now and adjust it later based
on attendees for specific topics if any.
On Thu, 14 Jan 2021 at 19:01, Jonathan Cameron via Linaro-open-discussions <
linaro-open-discussions(a)op-lists.linaro.org> wrote:
> On Thu, 14 Jan 2021 09:41:05 +0000
> Lorenzo Pieralisi via Linaro-open-discussions <
> linaro-open-discussions(a)op-lists.linaro.org> wrote:
>
> > On Mon, Jan 11, 2021 at 02:29:16PM +0000, Mike Holmes via
> Linaro-open-discussions wrote:
> > > Thanks all for another good discussion today, notes on the main topic
> of
> > > the cluster-aware scheduler are here [1]
> > >
> > > The next call is tentatively set for a month from now, on February 8th
> > > 2021 at 10.00 am GMT*, please bring forward any topics for that call
> > > (or any suggestions for a different or earlier call).
> >
> > Hi Mike,
> >
> > thank you. I can't make that week - if possible I would move it to
> > February 15th please depending on whether that's OK with others.
> >
> > Timezone-wise it would be good if we could accommodate also developers
> > from the western hemisphere but moving it to an afternoon call (in GMT)
> > would certainly upset people in the eastern timezones.
> >
> > Open to suggestions.
> >
> > Thank you very much all.
>
> Hi. As someone mentioned on the last call the dates are very near to the
> Chinese
> New Year. I've just checked with my China based colleagues and they
> advise against
> any meetings between the 10th and the 18th of February.
>
> So perhaps we fall back to the 22nd for the normal scheduled meeting,
> keeping in mind
> that we may want to do an additional one for the scheduler topic before
> then.
>
> Time wise, I think we will have to be flexible dependent on the agenda for
> a give call.
> At times we may have to even do repeated calls, though those are less than
> ideal.
>
> Jonathan
>
>
> >
> > Lorenzo
> >
> > > Mike
> > >
> > > [1]
> > >
> https://collaborate.linaro.org/display/LOD/2021-1-11+Meeting+Meeting+notes
> > > * Note that Chinese New year will start on February 11th 2021
> > > --
> > > Mike Holmes | Director, Foundation Technologies, Linaro
> > > Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
> > > "Work should be fun and collaborative, the rest follows"
> > > --
> > > 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
>
On Thu, 14 Jan 2021 09:41:05 +0000
Lorenzo Pieralisi via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote:
> On Mon, Jan 11, 2021 at 02:29:16PM +0000, Mike Holmes via Linaro-open-discussions wrote:
> > Thanks all for another good discussion today, notes on the main topic of
> > the cluster-aware scheduler are here [1]
> >
> > The next call is tentatively set for a month from now, on February 8th
> > 2021 at 10.00 am GMT*, please bring forward any topics for that call
> > (or any suggestions for a different or earlier call).
>
> Hi Mike,
>
> thank you. I can't make that week - if possible I would move it to
> February 15th please depending on whether that's OK with others.
>
> Timezone-wise it would be good if we could accommodate also developers
> from the western hemisphere but moving it to an afternoon call (in GMT)
> would certainly upset people in the eastern timezones.
>
> Open to suggestions.
>
> Thank you very much all.
Hi. As someone mentioned on the last call the dates are very near to the Chinese
New Year. I've just checked with my China based colleagues and they advise against
any meetings between the 10th and the 18th of February.
So perhaps we fall back to the 22nd for the normal scheduled meeting, keeping in mind
that we may want to do an additional one for the scheduler topic before then.
Time wise, I think we will have to be flexible dependent on the agenda for a give call.
At times we may have to even do repeated calls, though those are less than ideal.
Jonathan
>
> Lorenzo
>
> > Mike
> >
> > [1]
> > https://collaborate.linaro.org/display/LOD/2021-1-11+Meeting+Meeting+notes
> > * Note that Chinese New year will start on February 11th 2021
> > --
> > Mike Holmes | Director, Foundation Technologies, Linaro
> > Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
> > "Work should be fun and collaborative, the rest follows"
> > --
> > 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, Jan 11, 2021 at 02:29:16PM +0000, Mike Holmes via Linaro-open-discussions wrote:
> Thanks all for another good discussion today, notes on the main topic of
> the cluster-aware scheduler are here [1]
>
> The next call is tentatively set for a month from now, on February 8th
> 2021 at 10.00 am GMT*, please bring forward any topics for that call
> (or any suggestions for a different or earlier call).
Hi Mike,
thank you. I can't make that week - if possible I would move it to
February 15th please depending on whether that's OK with others.
Timezone-wise it would be good if we could accommodate also developers
from the western hemisphere but moving it to an afternoon call (in GMT)
would certainly upset people in the eastern timezones.
Open to suggestions.
Thank you very much all.
Lorenzo
> Mike
>
> [1]
> https://collaborate.linaro.org/display/LOD/2021-1-11+Meeting+Meeting+notes
> * Note that Chinese New year will start on February 11th 2021
> --
> Mike Holmes | Director, Foundation Technologies, Linaro
> Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
> "Work should be fun and collaborative, the rest follows"
> --
> 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
Hi,
There has been some discussion on the card QEMU-414:
https://projects.linaro.org/browse/QEMU-414
about adding another CPU model to QEMU that is somewhat more advanced
than the current v8.0 offerings but isn't quite the rolling "all the ARM
you can eat" -cpu max. So far the primary interest I'm aware of has come
from people working on the SBSA and BSA reference platforms who want to
have something with a few more features than the base v8.0 spec which we
have covered.
So far we have been mostly focused on adding architectural features that
are of direct interest to kernel and user space developers. This has
allowed testing of code that uses SVE, MTE and BTI instructions. However
there are no real CPUs that have quite the "random" assortment of
ARM features QEMU currently implements.
Implementing a new CPU model is not free either. We would have to back
fill features we have currently skipped - some fairly simple and others
not so much. We might also have to implement new on-chip devices (for
example GICv4). We are also not interested in implementing a "only in
QEMU" chip that has no real world analogue.
However to decide on real world chip to model we need to gather
requirements about what is it potential users need in this model? What
architectural features are most interesting and what real world chip
meets them?
I would like to here any feedback and maybe this could be a topic for a
future sync-up call?
--
Alex Bennée
On Mon, 7 Dec 2020 10:07:44 +0000
Marcin Juszkiewicz via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote:
> W dniu 03.12.2020 o 22:21, Alex Bennée pisze:
>
> > There has been some discussion on the card QEMU-414:
> >
> > https://projects.linaro.org/browse/QEMU-414
> >
> > about adding another CPU model to QEMU that is somewhat more advanced
> > than the current v8.0 offerings but isn't quite the rolling "all the ARM
> > you can eat" -cpu max. So far the primary interest I'm aware of has come
> > from people working on the SBSA and BSA reference platforms who want to
> > have something with a few more features than the base v8.0 spec which we
> > have covered.
> >
> > So far we have been mostly focused on adding architectural features that
> > are of direct interest to kernel and user space developers. This has
> > allowed testing of code that uses SVE, MTE and BTI instructions. However
> > there are no real CPUs that have quite the "random" assortment of
> > ARM features QEMU currently implements.
>
> Something like Cortex-A76/78 would be nice. v8.2 with RAS, VHE, VMID16,
> SMMUv3, PMUv3p1 etc.
>
> Several features are required by either BSA or higher levels of SBSA
> specs. For example crypto (SHA3, SHA512, SM3, SM4), SVE, MTE or Pointer
> Authentication.
>
> v8.5 added cache speculation side-channel attack migitations and they
> are required by BSA and SBSA level 6. They probably do not matter in
> QEMU but could be checked for existence.
>
> BSA mentions CBSA specification but it is not public yet so no
> information what requirements it adds.
>
> As any Arm licensee can choose which features they add to base v8.2 core
> I think that QEMU can have cortex-a76 with some selected features added
> on top (versioned or not - depends on QEMU devs decision).
>
> I attached HTML table with BSA and SBSA requirements which may be
> helpful with finding out which cpu/system features are required by
> specifications. It will be updated once CBSA gets published (or any new
> similar spec).
>
> > Implementing a new CPU model is not free either. We would have to back
> > fill features we have currently skipped - some fairly simple and others
> > not so much. We might also have to implement new on-chip devices (for
> > example GICv4). We are also not interested in implementing a "only in
> > QEMU" chip that has no real world analogue. >
> > However to decide on real world chip to model we need to gather
> > requirements about what is it potential users need in this model? What
> > architectural features are most interesting and what real world chip
> > meets them?
>
> SBSA Level 4 requires v8.3, SMMU v3 and GIC v3. Next levels bump CPU to
> v8.4/8.5 and SMMU to v3.2 while keeping GIC at v3.
>
> BSA also mentions only GIC v2/v2m/v3.
I forgot to feedback on this one having pestered a few people.
Generally it's features Huawei teams are interested in rather than emulating
a specific processor core or even SBSA level. If the gap happens to become
trivial enough it might be worth filling in the holes.
Jonathan
Thanks all for another good discussion today, notes on the main topic of
the cluster-aware scheduler are here [1]
The next call is tentatively set for a month from now, on February 8th 2021
at 10.00 am GMT*, please bring forward any topics for that call (or any
suggestions for a different or earlier call).
Mike
[1]
https://collaborate.linaro.org/display/LOD/2021-1-11+Meeting+Meeting+notes
* Note that Chinese New year will start on February 11th 2021
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative, the rest follows"
On Wed, Dec 09, 2020 at 09:14:46AM +0000, Jonathan Cameron via Linaro-open-discussions wrote:
> On Wed, 9 Dec 2020 08:35:57 +0000
> Mike Holmes via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote:
>
> > On Wed, Dec 9, 2020 at 8:19 AM Vincent Guittot via Linaro-open-discussions <
> > linaro-open-discussions(a)op-lists.linaro.org> wrote:
> >
> > > On Tue, 8 Dec 2020 at 18:02, Lorenzo Pieralisi via
> > > Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org>
> > > wrote:
> > > >
> > > > On Thu, Dec 03, 2020 at 01:40:55PM +0000, Jonathan Cameron wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > The previous thread has gotten rather convoluted, so I'm going to have
> > > a go at extracting
> > > > > a brief summary of topics and suggesting some straw man timings.
> > > > > These are all discussion topics, so name just indicates who I think
> > > will do the intro.
> > > > > Note I'd suggest we keep fairly tightly to timings and if it looks
> > > like a particular
> > > > > conversation is going long, we schedule a follow up.
> > > >
> > > > Hi Jonathan, all,
> > > >
> > > > thanks for the sync-up yesterday, I have already started following up
> > > > on some topics (ACPI CPU hotplug).
> > > >
> > > > I would like to put forward this topic for the next meeting agenda:
> > > >
> > > >
> > > https://lore.kernel.org/linux-acpi/20201201025944.18260-1-song.bao.hua@hisi…
> > > >
> > > > I think it is a discussion that would benefit from a conference like
> > > > discussion to add to mailing list discussions that already took place.
> > >
> > > I agree.
> > >
> >
> > I will add it to the call scheduled for the second week of January, but we
> > can do something before then if needs be.
>
> Sounds good. We'd kept clear of proposing this one previously because it
> was still at an early stage. Things have now moved on a bit on the lists so
> I agree it makes sense to have a discussion around this topic.
>
> There is an added complexity timing wise. Clearly we need Barry Song
> (song bao hua) and he is based in New Zealand so normal time isn't going to
> work. To be sensible, needs to end by 10am UK time.
>
> So to pin down a time, who do we need for this topic + who is interested?
>
> From our side I'd suggest
>
> Need: Barry (NZ),
It would be good as usual to have some slides prepared for the session
to get the discussion going, thank you very much.
Lorenzo
> Interested:
> Various UK and China based people including me :)
>
> Vincent and Lorenzo both expressed interest (both in Europe I think?)
>
> Thanks,
>
> Jonathan
>
>
> >
> >
> > >
> > > >
> > > > Please let me know if that's feasible.
> > > >
> > > > Thanks,
> > > > Lorenzo
> > > >
> > > > > VLPI Migration support on Gic V4.1: lushenming (Huawei) - 15 mins
> > > > > Topic requested by Lorenzo Pieralisi (ARM)
> > > > > In GICv4.1, migration has been supported except for
> > > (directly-injected)
> > > > > VLPI. And GICv4.1 spec explicitly gives a way to get the VLPI's
> > > pending
> > > > > state (which was crucially missing in GICv4.0). So we make VLPI
> > > migration
> > > > > capable on GICv4.1 in this patch set.
> > > > > (5 min) Intro to the work, then questions (10 min).
> > > > >
> > > > > vCPU HP: Salil Mehta (Huawei) 25 mins.
> > > > > Lorenzo has questions + it's an expansive topic.
> > > > > I would suggest interested people catch up with slides from KVM
> > > forum 2020
> > > > >
> > > https://kvmforum2020.sched.com/event/eE4m/challenges-in-supporting-virtual-…
> > > (video not public yet)
> > > > > (5 min) Open questions statement, then move to discussion.
> > > > >
> > > > > RMR related topics - follow up on last call: Lorenzo Pieralisi (ARM) -
> > > 5 mins
> > > > > There were outstanding questions around whether PCIe reenumeration
> > > could
> > > > > cause problems here.
> > > > > (Lorenzo, Shameer, there were a few other open questions around this
> > > topic,
> > > > > do we have any other updates for Monday?)
> > > > >
> > > > > Generic Initiators: Jonathan Cameron (Huawei) - 5 mins
> > > > > Very brief intro to GIs + current status + opening for questions.
> > > > > More detail etc in this email.
> > > > >
> > > https://op-lists.linaro.org/pipermail/linaro-open-discussions/2020-November…
> > > > >
> > > > > Ideally slides should go to Mike in advance to upload to the
> > > collaborate page.
> > > > >
> > > > > Anything I've missed?
> > > > >
> > > > > 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 mailing list
> https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
> https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions