Linaro-open-discussions December 2020

linaro-open-discussions@op-lists.linaro.org

12 participants
13 discussions

Re: [Linaro-open-discussions] QEMU's next v8-A emulation model

by Jerome Forissier

On 12/3/20 10:21 PM, Alex Bennée via Linaro-open-discussions wrote: > > 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. Perhaps more related to '-cpu max' than to what you're asking specifically, but what about S-EL2 support? One day or another it could come in handy for OP-TEE testing and debugging for instance. Thanks, -- Jerome

3 years, 4 months

SCMI server in TEE

by Vincent Guittot

Hi All, A meeting about the SCMI server is scheduled Wednesday, Dec 9th. Among the topics, we will discuss how to abstract SCP-firmware on different Os and enable multiple event queues in single threaded mode. All details to join the meeting can be found here: https://collaborate.linaro.org/display/SCMI Regards, Vincent

3 years, 4 months

Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting 4 Nov 2020

by Lorenzo Pieralisi

On Thu, Nov 26, 2020 at 08:47:45AM +0000, Jonathan Cameron wrote: > Hi Mike, > > > > lushenming is happy to present / discuss the topic Lorenzo requested. > > > > https://lore.kernel.org/linux-arm-kernel/ > 20201123065410.1915-1-lushenming(a)huawei.com > > For agenda list please add “VLPI Migration support on Gic V4.1” Thanks ! > Lorenzo also mentioned he had an update on > > “Use of BDF to identify PCI devices in ACPI tables” > > which I’d definitely like to be on the agenda. On this it is rather that I had the IORT specs firmed up so the bus re-enumeration is not a problem anymore. Side note: I noticed that in x86 world RMR the PCI topology is described hierarchically with dev-function pairs starting from the root bus but we don't want to go that way in IORT - I don't necessarily see a reason for that. Let's speak. > Final topic that has been discussed for inclusion is > > “vCPU hotplug” > > Let’s move that up to confirmed topics. Yes. I have a couple of questions on this topic so we can and probably should move it up the agenda because they can take some time. Lorenzo > It’s going to be a full agenda, so I suggest we try to share slides in advance > and we keep > > to a fairly tight schedule! > > > > For those doing slides, I assume best approach is email them to you Mike and > you upload > > them to the collaborate page? Perhaps if people could also let Mike know > expected time > > needed (always a guess) then we can decide to spill some topics to a future > meeting or > > email discussion if necessary. > > > > Thanks, > > > > Jonathan > > > > > > From: Mike Holmes [mailto:mike.holmes@linaro.org] > Sent: 26 November 2020 07:28 > To: Jonathan Cameron <jonathan.cameron(a)huawei.com> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>; > linaro-open-discussions(a)op-lists.linaro.org > Subject: Re: [Linaro-open-discussions] Notes on Linaro Open Discussions meeting > 4 Nov 2020 > > > > I see a lot of new subscriptions to the list - welcome. > > Here is the updated meeting slot poll for the week of December 7th to December > 12th > > https://doodle.com/poll/sgy9esiim4rapitz?utm_source=poll&utm_medium=link > > > > Agenda > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > > > > > > On Wed, Nov 25, 2020 at 4:14 PM Jonathan Cameron <Jonathan.Cameron(a)huawei.com> > wrote: > > On Wed, 25 Nov 2020 16:05:51 +0000 > Mike Holmes <mike.holmes(a)linaro.org> wrote: > > > On Wed, Nov 25, 2020 at 4:01 PM Lorenzo Pieralisi via > > Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> > wrote: > > > > > On Wed, Nov 25, 2020 at 03:22:19PM +0000, Jonathan Cameron wrote: > > > > On Wed, 25 Nov 2020 13:58:38 +0000 > > > > Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> wrote: > > > > > > > > > On Wed, Nov 25, 2020 at 12:51:49PM +0000, Jonathan Cameron wrote: > > > > > > > > > > [...] > > > > > > > > > > > > Is December 2nd confirmed as next session ? If possible 3PM > GMT > > > works > > > > > > > better for me; the NUMA topic raised by Jonathan is another > > > interesting > > > > > > > topic for debate. > > > > > > > > > > > > Just to check, which NUMA topic? > > > > > > > > > > > > > https://op-lists.linaro.org/pipermail/linaro-open-discussions/ > 2020-November/000016.html > > > > > > > > > > It would be useful (for me certainly) if you can give an update on > > > > > what's still pending in the items in the discussion above (eg it is > > > > > not clear what the "PCI fix" is) + how it is linked to CXL. > > > > > > > > Sure, that should be a fairly short topic, but I'm happy to try to > fill > > > in the gaps. > > > > @Mike, can you add "Generic initiators - pending items" to the > agenda. > > > > > > > > For the PCI 'fix' it is this one that got applied and then reverted > in > > > 4.20 timeframe > > > > > > > http://patchwork.ozlabs.org/project/linux-pci/patch/ > 20180912152140.3676-2-Jonathan.Cameron(a)huawei.com/ > > > > I've not rebased or tested it recently so I'll check that it still > > > appears to be right > > > > before the call. > > > > > > > > > > > > > > The vCPU hotplug is also worth adding (even though I do not know > what > > > > > was discussed at KVM forum). > > > > > > > > I was just about to email about that one. From our side, all that > is > > > currently > > > > going on around vCPU Hotplug is a rebase. At KVM forum Mark R > kindly > > > offered > > > > to see if he could find out answers to a few open questions. > Perhaps > > > catch > > > > up with Mark, or see if he can make the call? > > > > > > Ok, will catch up with him, it is probably better if I have some time > > > to do it (ie postpone the call for a week). > > > > > > > > Furthermore, I am keen on discussing this: > > > > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/ > 20201123065410.1915-1-lushenming(a)huawei.com > > > > > > > > > > if the submitters are available, it would help to get some context > in > > > > > relation to upstream discussions. > > > > > > > > I've messaged lushenming so hopefully we can sort out something on > that > > > front. > > > > > > > > Looks like finding a time next week is proving challenging. If that > > > > fails, perhaps we should try for the week after? > > > > > > Yes we can, it would be easier to prepare the topics and find a > suitable > > > day as well, next week it looks like it is challenging. It would also > > > give us some time to extend the invite. > > > > > > Please let me know and apologies to Mike for all these emails to get it > > > organized. > > > > > > > No problem, as soon as it is confirmed we want to try for the following > > week I can set up a poll to pick the day and hour > > Definitely sounds like a better plan. Fingers crossed people have slightly > more open schedules that week! > > Thanks for sorting this out Mike. > > Jonathan > > > > > > > > > > > Thanks, > > > Lorenzo > > > > > > > Thanks, > > > > > > > > Jonathan > > > > > > > > > > > > > > > > > > Thanks ! > > > > > Lorenzo > > > > > > > > > > > I've lost track of what we are talking about. > > > > > > > > > > > > > Other than that we can slot in the topics that > > > > > > > weren't discussed last time: > > > > > > > > > > > > > > > > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > > > > > > > > > > > > > even though those require a bit of preparation so the sooner > we > > > finalize > > > > > > > the schedule the better. > > > > > > > > > > > > Seems we have clashed with some internal Huawei activities so > some > > > people who > > > > > > would normally be active are snowed under this week. > > > > > > > > > > > > Jonathan > > > > > > > > > > > > > > > > > > > > Please let me know, thanks. > > > > > > > > > > > > > > Lorenzo > > > > > > > > > > > > > > > * DT alignment. Don't want different solutions for each > firmware > > > type. > > > > > > > > * Lorenzo / Sami to check IORT revision E is final. > > > > > > > > > > > > > > > > SVA > > > > > > > > === > > > > > > > > > > > > > > > > Zangfei gave summary: > > > > > > > > - Huawei has devices that are not PCIe but are presented as > > > such. > > > > > > > > - They support stall mode for SVA (spec violation) > > > > > > > > - Resistance from kernel maintainers to maintaining a white > > > list for any quirk. Fine to fix > > > > > > > > it once (JPB), but not to keep doing so. > > > > > > > > - Note that stall mode not yet supported at all (JPB to > send > > > out this cycle). > > > > > > > > - If longer term fix need add can't be done via PCISIG etc > then > > > need to convince > > > > > > > > PCI and SMMU maintainers. Noted that quirk is very > little > > > code. > > > > > > > > > > > > > > > > * Other SVA topics. > > > > > > > > - Mentioned virtual SVA (no actually problems just > expressing > > > interest!) > > > > > > > > - Would need Eric Auger, wasn't on topic list so Eric not > on > > > call. > > > > > > > > > > > > > > > > AI: Nothing planned until after JPB has upstreamed stall > mode. > > > Hard to have discussion before that. > > > > > > > > > > > > > > > > DVFS > > > > > > > > ==== > > > > > > > > > > > > > > > > guohanjun > > > > > > > > > > > > > > > > Solutions exist for > > > > > > > > * CPU DVFS (voltage + frequency scaling) > > > > > > > > * PCIe device power states etc > > > > > > > > > > > > > > > > No standard way of controlling Uncore voltage and frequency > for > > > ACPI based systems. > > > > > > > > > > > > > > > > 3 options: > > > > > > > > 1. MMIO / kernel driver. > > > > > > > > 2. PSCI via trusted firmware and system management > controller. > > > > > > > > 3. ACPI (wrapping up an op region and SCMI) > > > > > > > > > > > > > > > > Clarifications / discussions. > > > > > > > > * Vincent G: Power states, or voltage frequency of interest? > > > > Ans Voltage Freq > > > > > > > > * Considered SCMI? Ans: Works only for DT as SCMI under > ACPI > > > is wrapped up in AML > > > > > > > > so looks like an ACPI interface. > > > > > > > > * Sudeep H: Necessary to trace CPU freq? Yes. > > > > > > > > * Sudeep H: Why not do it in firmware entirely? Ans. Not > just > > > CPU. For example PCI device accessing > > > > > > > > memory may well need the ring bus to be fast. > > > > > > > > * Vincent G: Bandwidth affected? Yes. VG: mobile does this > by > > > specifying a BW requirement (via SCMI.- > > > > > > > > * Sudeep H Observed need to expose it via ACPI spec. (option > 3 > > > above). > > > > > > > > * Sudeep H: Does PCI also need fine-grain control? We might > > > need to add to the spec. > > > > > > > > * Sudeep H: What are the requirements? gaohanjun: Now we > just > > > frequency scaling. > > > > > > > > * Jonathan C: Noted PCI power state is not enough. It's > > > workload dependent. > > > > > > > > * Sudeep H: We need to gather all the info, need to talk in > > > ASWG about DVFS > > > > > > > > * Jonathan C: For now direct control probably makes sense. > > > Whilst it would be nice to have > > > > > > > > a detailed enough system description in a standard way to > > > make general software that is a > > > > > > > > big spec job. > > > > > > > > * Jonathan C: Seems like true standard SW will not happen > any > > > time soon. > > > > > > > > > > > > > > > > AI: RFC to the linux-pm / linux-acpi Rafael and those in > this > > > discussion to ask about > > > > > > > > interest in adding per device DVFS to ACPI spec. > Possibly > > > pursue code first ACPI > > > > > > > > approach. > > > > > > > > > > > > > > > > If I've miss listed or "volunteered" anyone for AIs they > didn't > > > agree to then please > > > > > > > > correct that. > > > > > > > > > > > > > > > > Thanks all for contributions. I for one found it a very > useful > > > call! > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > -- > > Mike Holmes | Director, Foundation Technologies, Linaro > > Mike.Holmes(a)linaro.org > > "Work should be fun and collaborative, the rest follows" > > > >

3 years, 4 months

2024

2023

2022

2021

2020

Linaro-open-discussions December 2020