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

Re: [Linaro-open-discussions] Linaro Open Discussions Kernel topics - Meeting Notes 2021-1-11

by Jonathan Cameron

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

3 years, 3 months

1
0
0 0

Re: [Linaro-open-discussions] Linaro Open Discussions Kernel topics - Meeting Notes 2021-1-11

by Lorenzo Pieralisi

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

3 years, 3 months

1
0
0 0

QEMU's next v8-A emulation model

by Alex Bennée

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

3 years, 3 months

3
3
0 0

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

by Jonathan Cameron

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

3 years, 3 months

2
2
0 0

Linaro Open Discussions Kernel topics - Meeting Notes 2021-1-11

by Mike Holmes

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"

3 years, 3 months

1
0
0 0

Re: [Linaro-open-discussions] Suggested Agenda / timings for Monday 7 Dec call

by Lorenzo Pieralisi

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

3 years, 3 months

2
1
0 0

Re: [Linaro-open-discussions] Suggested Agenda / timings for Monday 7 Dec call

by Mike Holmes

Yes I think we settled on Monday, 11 January⋅10:00 – 11:00am GMT Confirmed topics - Lorenzo Pieralisi : Arm : Scheduler topology: cluster scheduler awareness - https://lore.kernel.org/linux-acpi/20201201025944.18260-1-song.bao.hua@hisi… - Lorenzo Pieralisi : Arm : ACPI CPU hotplug https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home Monday, 11 January⋅10:00 – 11:00am GMT Join Zoom Meeting https://linaro-org.zoom.us/j/4417312160 Meeting ID: 441 731 2160 One tap mobile +16465588656,,4417312160# US (New York) +16699009128,,4417312160# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Washington D.C) +1 312 626 6799 US (Chicago) +1 346 248 7799 US (Houston) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 441 731 2160 Find your local number: https://linaro-org.zoom.us/u/acqrJhJKGC On Mon, Jan 4, 2021 at 5:13 PM Lorenzo Pieralisi via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote: > On Thu, Dec 10, 2020 at 09:15:23AM +0000, Lorenzo Pieralisi via > Linaro-open-discussions wrote: > > 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), > > > > > > Interested: > > > Various UK and China based people including me :) > > > > > > Vincent and Lorenzo both expressed interest (both in Europe I think?) > > > > +4-5 ARM folks (me inclusive) - all based in Europe. > > Hi and Happy New Year all !! > > Is the time for the call next Monday finalized ? I would like to > firm it up as soon as possible so that I can invite the relevant > people on the Arm side and others possibly interested. > > Also it would be useful to add it to the calendar. > > Please let me know, thank you very much. > > Lorenzo > -- > 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 <mike.holmes(a)linaro.org> "Work should be fun and collaborative, the rest follows"

3 years, 3 months

2
1
0 0

Re: [Linaro-open-discussions] Suggested Agenda / timings for Monday 7 Dec call

by Lorenzo Pieralisi

On Thu, Dec 10, 2020 at 09:15:23AM +0000, Lorenzo Pieralisi via Linaro-open-discussions wrote: > 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), > > > > Interested: > > Various UK and China based people including me :) > > > > Vincent and Lorenzo both expressed interest (both in Europe I think?) > > +4-5 ARM folks (me inclusive) - all based in Europe. Hi and Happy New Year all !! Is the time for the call next Monday finalized ? I would like to firm it up as soon as possible so that I can invite the relevant people on the Arm side and others possibly interested. Also it would be useful to add it to the calendar. Please let me know, thank you very much. Lorenzo

3 years, 3 months

1
0
0 0

PCI BDF in ACPI table - In reality does Linux ever actually change these?

by Jonathan Cameron

Hi Lorenzo, All, Before potentially sending out an ECR for ACPI to require the _DSM that prevents PCI related resource reassignment (in GI case), I thought I would do some experiments to see if there is another potential solution (this obviously doesn't work for RMR case!) Can we cache the state (BDF of each device) that the firmware has configured, to build a hierarchical representation that we can then use to put figure out the association after reenumeration? My assumption is this should be possible, and the vIOMMU spec of JPB (which has the same BDF issue) kind of suggests this solution. https://jpbrucker.net/virtio-iommu/viot/viot-v9.pdf "This identifier corresponds to the one observed by the operating system when parsing the PCI configuration space for the first time after boot" So the problem I've run into is I can't actually build a test setup where the BDFs of devices correctly configured by the firmware are changed. Note this is all in QEMU with various hacks in EDK2 including enablement of root port padding from OVMF (I'll post that for merging into EDK2 at somepoint because it's useful.) Whilst qemu doesn't seem to allow hotplug of a PCIe switch I can plug a pcie-pci-bridge to exercise pretty much the same code paths. As an alternative, if we stop EDK2 from enabling a switch upstream port, the kernel will attempt that later and it can go horribly wrong. Side questions on whether we may want to look at hardening that code against random broken situations. It's not high on my priority list but I might post an RFC on that at some stage as it can take a working partial pci topology and end up with nothing at all working as uses bus numbers multiple times. But if the configuration is valid, I can't seem to actually build a setup where the BDF changes. It's relatively easy to get the various other resources to change (e.g. discussion on adding _DSM to qemu ACPI ongoing has some examples), but not the BDF. https://lore.kernel.org/qemu-devel/20201217132926.4812-1-cenjiahui@huawei.c… Obviously, nothing stops Linux or another OS doing this in future if the _DSM isn't provided. To a certain extend I don't really care if Linux does or doesn't re-enumerate the bus numbers but being unable to make it happen does make it rather tricky to build a PoC of the caching approach. Any thoughts, or known configurations in which will change existing bus number assignments? The code is fiddly so there are a few places where it looks like it will but then turns out to not do so because of a sanity check elsewhere. Jonathan p.s. No rush on this as I'll be off until January from end of today.

3 years, 4 months

2
1
0 0

Re: [Linaro-open-discussions] Suggested Agenda / timings for Monday 7 Dec call

by Mike Holmes

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. > > > > > 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 > -- 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"

3 years, 4 months

2
2
0 0

2024

2023

2022

2021

2020

Linaro-open-discussions