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

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

4 years, 7 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

4 years, 7 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"

4 years, 7 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

4 years, 7 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"

4 years, 7 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

4 years, 7 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.

4 years, 8 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"

4 years, 8 months

2
2
0 0

Re: [Linaro-open-discussions] Compass CI and LKFT follow up - Dec 10

by wufengguang

Hi All, It's a nice and productive meeting. Thanks to Anmar for the summary. A small note: > 17+ machines in CompassCI lab now. Maybe start with 1 machine for Sorry that I didn't speak the "17" part clearly. In the conversation, I was talking about archlinux AUR packages that end with -git. I just double checked and find the number is "14k" not "17k". These PKGBUILD scripts are readily usable for running build tests for the upstream. As for machines in our lab, you can see the exact list here: https://gitee.com/wu_fengguang/lab-z9/tree/master/hosts Thanks, Fengguang

4 years, 8 months

1
0
0 0

Re: [Linaro-open-discussions] [Lkq-dev] Compass CI and LKFT follow up - Dec 10

by Jammy Zhou

Hi, The meeting minutes are summarized below. Thanks for attending. MINUTES: Vendor remote lab is interesting to openEuler for wide hardware coverage. - Leverage existing Linaro LKFT Lab + remote lab - e.g, NXP remote lab (shared by NXP, Linaro, KernelCI) - https://lavalab.nxp.com/ - CompassCI also has plan for remote lab support CompassCI also has the capability for bisecting support (the algorithm can be universal to both kernel and user space applications). LKP itself doesn’t have the bisecting capability. TuxSuite is focusing mainly on the kernel part. Paolo: is it functional or performance bisecting in CompassCI? Fengguang: currently functional, performance support will be added later CompassCI starts from upstream, and then downstream (so not only downstream kernel). Arch Linux package build is used by CompassCI, so it is easy to add different kernel builds. Scale testing with QEMU (e.g, run openEuler on Kunpeng 920, and run multiple QEMU instances on openEuler), and it can be deployed via remote lab. Fengguang: it is nice. 17+ machines in CompassCI lab now. Maybe start with 1 machine for prototyping (the dispatcher can run on the same machine for QEMU case). Anmar: the dispatcher is fully dockerized now, there should be no big issue to run on openEuler. Paolo: modularization can be helpful to merge the benefits of both Paolo: Is the part for performance bisecting ready in CompassCI? Fengguang: not yet Paolo: maybe we can work together to have some common solution to avoid reinventing the wheel. It’s under design for LKFT so it’s a good place for us to collaborate. Fengguang: Focus is on build now then the benchmark testing. Anmar: the Linaro team and Fengguang to connect later on to make sure the tool is useful for both CI systems. Questions and Answers: - Q. Can LKP run without having to install packages or tests, only the job definitions (scripts) ? If we can run tests without having to install the pre-req every time, that will speed up testing if we use a rootfs that has all its pre-req installed. - A. Compass CI has cpio archives it uses to overlay the tests dependencies to speed the test runs. These overlays are pre-built and available to the Compass-CI system - Q. We want to get a better understanding of the compare functionality - A. compare fetches different results and presents them. Nothing more. - Q. What are the plans for alignment with upstream LKP? By examining the https://github.com/fengguang/lkp-tests and comparing it to https://github.com/intel/lkp-tests.git, it seems the trees started diverging in March 2020. - A. Fengguang’s LKP-tests repo is periodically re-based on the upstream LKP-tests repo every couple of months. There is effort to push some of the changes back upstream but been minimal so far. Most of the tests run on Arm64 so from a testing perspective, Arm64 is well represented. It’s also not clear if LKP will accept many patches at the moment. However, a discussion needs to happen with the upstream at some point in time. - Q. How difficult is it to modularise the following LKP components: - Monitors - Tests - Test-plans - Email reports - Harmonizing output - Functional - Benchmark - Regression detection - A. LKP is already modularized and functions as a pipeline. Regards, Jammy On Wed, 9 Dec 2020 at 17:03, Jammy Zhou via Lkq-dev < lkq-dev(a)op-lists.linaro.org> wrote: > Hi All, > > We're going to have some follow up discussion about Compass CI and LKFT. > Welcome to join. > > @Anmar, please help share the detailed agenda to the list when available. > > ------ > Topic: CompassCI/LKFT follow up discussion > Time: Dec 10, 2020 09:00 PM Hong Kong SAR > > Join Zoom Meeting > https://linaro-org.zoom.us/j/97232094091 > > Meeting ID: 972 3209 4091 > One tap mobile > +16699009128,,97232094091# US (San Jose) > +12532158782,,97232094091# US (Tacoma) > > Dial by your location > +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) > +1 646 558 8656 US (New York) > 888 788 0099 US Toll-free > 877 853 5247 US Toll-free > Meeting ID: 972 3209 4091 > Find your local number: https://linaro-org.zoom.us/u/ad2qaJfAiY > > Regards, > Jammy > -- > Lkq-dev mailing list > Lkq-dev(a)op-lists.linaro.org > https://op-lists.linaro.org/mailman/listinfo/lkq-dev >

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

Linaro-open-discussions