Hi Ulf,
Sorry for the late reply, please see my comments inline.
On 2020/11/6 22:37, Ulf Hansson via Linaro-open-discussions wrote:
> On Fri, 6 Nov 2020 at 09:53, Mike Holmes via Linaro-open-discussions
> <linaro-open-discussions(a)op-lists.linaro.org> wrote:
>> All
>>
>> Thanks for a good discussion yesterday, Hanjun's Unconre DVFS slides are
>> now attached to the notes at
>> https://collaborate.linaro.org/display/LOD/2020-11-04+Meeting+Meeting+notes
> Just to make sure people know about it...
>
> For DT based platforms we have recently enabled a generic solution in
> the Linux kernel to support DVFS. From a top level point of view, it
> consists of letting a power-domain provider act as the backend driver
> for changing the performance state (voltage/frequency). The mapping of
> what state to select, is done through OPP tables.
>
> I am not an expert of ACPI specifications, but perhaps the DT bindings
> can be used as inspiration for what is missing!?
Could you point me to the patches or documentation?
Thanks
Hanjun
Hi All,
CompassCI [1] is a new CI testing framework being worked on by the
openEuler community, and the implementation is available in gitee repo [2].
We're going to have a conference call to discuss the potential
collaborations between CompassCI and LAVA/LKFT. The tech leader of
CompassCI will do some introduction about CompassCI and present their ideas
about integrating LAVA/LKFT with CompassCI. Below is the meeting info and
welcome to join.
Topic: Compass-CI and LAVA/LKFT sync
Time: Nov 17, 2020 09:00 PM Hong Kong SAR (UTC +8)
Join Zoom Meeting
https://linaro-org.zoom.com.cn/j/97479537073
Meeting ID: 974 7953 7073
One tap mobile
+16699009128,,97479537073# US (San Jose)
+12532158782,,97479537073# 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: 974 7953 7073
Find your local number: https://linaro-org.zoom.com.cn/u/aFYmaUrqs
[1] https://compass-ci.openeuler.org/
[2] https://gitee.com/openeuler/compass-ci
Regards,
Jammy
On Wed, Nov 04, 2020 at 01:23:43PM +0000, Jonathan Cameron via Linaro-open-discussions wrote:
> Hi All,
>
> This one made it onto the list of topics to discuss (now marked as no need
> to discuss). I've been meaning to give a status update by email including
> what is outstanding here. Please let me know if this fails to cover
> some aspect of interest.
>
> Background:
>
> https://github.com/hisilicon/acpi-numa-whitepaper/releases/tag/v0.93 chapter 3.
>
> Generic initiators are a concept in ACPI 6.3 (sec 5.2.16.6) to plug a hole
> in the definition of proximity domains.
>
> Proximity domains in ACPI (NUMA nodes in kernel) are defined by entries in SRAT
> table. There are a whole range of different types of SRAT entry but before
> ACPI 6.3 this more or less in practice meant that a proximity domain only
> existed if it contained either (or both) memory and CPUs. Other initiators
> of memory transactions such as network cards can be assigned to an existing
> proximity domain via _PXM in ACPI DSDT. This restricted them to sharing a domain
> with either memory or processors.
>
> That doesn't always reflect system architecture, particularly with the addition
> of richer descriptions of access characteristics (latency / bandwidth) brought
> in by HMAT. Hence Generic Initiator domains to allow you to specify a
> proximity domain with some other type of device in it (such as a network card)
> and get all of the descriptive capability available for CPU / memory nodes.
>
> Note that this was brought in prior to CXL becoming public but 1.1 CXL spec
> states that initiators on CXL should be described using Generic Initiator nodes.
> This should accelerate the number of users of this feature considerably.
> It is also useful in some existing systems.
>
> What support was needed in kernel:
>
> 1) Parsing of the SRAT Generic Initiator Affinity Structure
> 2) Instantiating the NUMA nodes that map to the GI PXM nodes to ensure stuff
> like fallback lists for memory allocation work as normal.
> 3) Richer use of HMAT access characteristics to differentiate nearest CPU
> to memory from nearest initiator to memory.
> 4) PXM assignment from the SRAT record rather than _PXM (not yet done).
> 5) PCI PXM assignment (not yet done)
>
> Status:
>
> The kernel patches sat on the list (with rebases) for well over a year
> failing to get the architecture review needed (as there was significant
> risk of breakage in both ARM64 and x86). It was to break this blockage
> that we were interested in an open discussion on this. However, they did
> recently get x86 review this and Rafael queued them for 5.10 (now merged)
>
> The PCI PXM issue has been long standing due to some buggy firmware
> on certain X86 boards and the need for a clarification in the ACPI spec
> (added in 6.3). To make this safe, needed to ensure that NUMA nodes on
> ACPI systems can only be instantiated during the main parse of SRAT.
>
> https://lore.kernel.org/linux-mm/20200818142430.1156547-1-Jonathan.Cameron@…
>
> That fix is now in place, and we'll resend the PCI fix shortly.
Overall, this is a topic to be discussed since it is important.
Shorter term, I need to pick your brain on this:
1) The series above, it should fix this issue:
https://lore.kernel.org/lkml/26284ca5-ea05-0496-629d-9951f49dda8f@linux.ali…
Correct ?
2) Why in dummy_numa_init() (arch/arm64/mm/numa.c) we don't turn
numa_off == true if numa_add_memblk() fails ?
(Side note: I really like the comment :) "...It is unlikely that this
function fails."
Forgive me for not looking earlier into the series above that Rafael
merged - as I said above this deserves more attention on my side.
Thanks,
Lorenzo
> Note it may be "interesting" to support nodes from CXL CDAT tables at runtime
> but that is another topic.
> ( https://uefi.org/node/4093https://lore.kernel.org/linux-cxl/20201102183428.00005f4f@Huawei.com/T/#m52… )
>
> For a Generic Initiator Nodes, there are two ways a device an be assigned
> to the proximity domain. Conventional _PXM in DSDT can be used and
> that is now supported. The SRAT entry itself also contains an address
> (PCI seg + BDF or Platform UID / HID based). There is no obligation to
> provide both. The SRAT based method will require some level of alternative
> infrastructure to that used for _PXM. We may look at this at some stage.
>
> So a few outstanding things but probably not worth discussing on a call
> at this stage unless anyone is seeing problems with the stuff already merged.
>
> 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
Hi all,
As previously announced we are hosting a kickoff meeting for the above
topic/project.
The meeting has been added to the linaro-open-discussions calendar,
according to the below. Feel free to join us on Thursday this week!
Kind regards
Ulf Hansson, Linaro KWG
When:
Thursday Nov 12, 16:00-17:00 CET.
Agenda:
1. Introduction.
2. Update of the current support in Linux.
3. Collaborations.
4. Technical things.
5. Other matters.
To join the Zoom Meeting:
https://linaro-org.zoom.us/j/97261221687
Meeting ID: 972 6122 1687
One tap mobile
+13462487799,,97261221687# US (Houston)
+16465588656,,97261221687# US (New York)
Dial by your location
+1 346 248 7799 US (Houston)
+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 (Germantown)
+1 312 626 6799 US (Chicago)
Meeting ID: 972 6122 1687
Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE
Hi All
We have an interesting call this week with input from Huawei, Windriver and
a discussion on the use of Greybus to solve the i2c, SPI and GPIO
virtualization cases.
- Salil Mehta - discussion on Huawei's interest in the Stratos project
- Dan Milea, Josh Pincus - OpenAMP App-services topics from WindRiver
- A couple of slides on Immediate goals, some research, some results,
and then immediate next steps
- Notes from recent presentations here
https://github.com/OpenAMP/open-amp/wiki/OpenAMP-Application-Services-Subgr…
- Viresh, Alex Elder, Bill Mills Greybus as a solution for I2C, SPI
and GPIO
------
Project Stratos Sync
Home page: https://collaborate.linaro.org/display/STR/Stratos+Home
<https://collaborate.linaro.org/display/STR/Stratos+Home>
Virtual meeting: meet.google.com/uak-yrcj-tyd
Thursday, 12 November⋅3:00 – 4:00 pm GMT
Every 2 weeks on Thursday
Mike
--
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 Fri, 6 Nov 2020 at 09:53, Mike Holmes via Linaro-open-discussions
<linaro-open-discussions(a)op-lists.linaro.org> wrote:
>
> All
>
> Thanks for a good discussion yesterday, Hanjun's Unconre DVFS slides are
> now attached to the notes at
> https://collaborate.linaro.org/display/LOD/2020-11-04+Meeting+Meeting+notes
Just to make sure people know about it...
For DT based platforms we have recently enabled a generic solution in
the Linux kernel to support DVFS. From a top level point of view, it
consists of letting a power-domain provider act as the backend driver
for changing the performance state (voltage/frequency). The mapping of
what state to select, is done through OPP tables.
I am not an expert of ACPI specifications, but perhaps the DT bindings
can be used as inspiration for what is missing!?
[...]
Kind regards
Ulf Hansson, Linaro KWG
On Thu, Nov 05, 2020 at 12:36:21PM +0000, Jonathan Cameron via Linaro-open-discussions wrote:
[...]
> IORT - Reserve memory regions (RMR)
> ===================================
>
> * Shameer gave summary
> - IORT Revision E (https://developer.arm.com/documentation/den0049/latest/) introduced new node type.
> - A way to describe memory regions that should have unity mapping in the SMMU.
> - Use case is a PCIe RAID card that has FW that uses a pool of host memory (hidden from OS).
>
> * Status
> - Patches out for ACPICA
> - Question raised by ACPICA reviewers on whether spec is final
> - Spec appears final (Lorenzo to check) but may be minor unrelated fix in doc to come (Sami).
> - Patches out for kernel on relevant lists.
> - Mail from Steven Price (Arm) - (Sami Mujawar who was on the call also involved) interested for EFI
> framebuffer use case.
>
> * Open questions
> - Equivalent from AMD has flag to indicate that unity mapping only needed until driver has taken over
> (end of kernel boot assumed). Avoids and issue of holes in address space for VMs.
> - Huawei not raising this as a requirement, but Lorenzo observed interesting and deserves discussion.
May I ask a pointer pls to relevant AMD docs and patches (if there are any) ?
Thanks,
Lorenzo
On Thu, Nov 5, 2020 at 11:38 AM Hanjun Guo via Linaro-open-discussions
<linaro-open-discussions(a)op-lists.linaro.org> wrote:
>
> On 2020/11/2 17:47, Mike Holmes via Linaro-open-discussions wrote:
> > Topic: Linaro Open Discussions [1] - Kernel related
> > Time: Nov 4, 2020 02:00 PM London
> > ------
> > Agenda [2]
> >
> > - Hanjun/Shameer - IORT reserved memory support
> > - Zhangfei/Wangzhou - SVA support for SMMU stall mode
> > - Hanjun - Uncore DVFS and how to support it (needs spec update, either
> > ARM specs or ACPI)
>
> Please see attached slide for the discussion.
file is uploaded and available here:
https://collaborate.linaro.org/download/attachments/147424278/Uncore%20DVFS…
>
> Thanks
> Hanjun
>
> >
> >
> > [1] Linaro Open Discussions Home
> > <https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home>
> > For all open meeting schedules
> > [2] 2020-11-04 Proposed Meeting Agenda
> > <https://collaborate.linaro.org/display/LOD/2020-11-04+Proposed+Meeting+Meet…>
> >
> > ----------
> > Join Zoom Meeting
> > https://linaro-org.zoom.us/j/98027304997
> >
> > Meeting ID: 980 2730 4997
> > One tap mobile
> > +16699009128,,98027304997# US (San Jose)
> > +12532158782,,98027304997# US (Tacoma)
> >
> > Dial by your location
> > +1 669 900 9128 US (San Jose)
> > +1 253 215 8782 US (Tacoma)
> > +1 301 715 8592 US (Germantown)
> > +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: 980 2730 4997
> > Find your local number: https://linaro-org.zoom.us/u/aehAhwidV2
> >
> --
> 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
All
Thanks for a good discussion yesterday, Hanjun's Unconre DVFS slides are
now attached to the notes at
https://collaborate.linaro.org/display/LOD/2020-11-04+Meeting+Meeting+notes
Please raise any further topics for discussion. I will put in a
tentative call in the calendar for the first Wednesday in December. Still,
the topics and dates are completely open and feel free to post here if
other topics are being discussed elsewhere any you feel extra ears may
benefit.
Mike
--
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"
Hi Hanjun,
On Thu, Nov 5, 2020 at 11:38 AM Hanjun Guo via Linaro-open-discussions <
linaro-open-discussions(a)op-lists.linaro.org> wrote:
> On 2020/11/2 17:47, Mike Holmes via Linaro-open-discussions wrote:
> > Topic: Linaro Open Discussions [1] - Kernel related
> > Time: Nov 4, 2020 02:00 PM London
> > ------
> > Agenda [2]
> >
> > - Hanjun/Shameer - IORT reserved memory support
> > - Zhangfei/Wangzhou - SVA support for SMMU stall mode
> > - Hanjun - Uncore DVFS and how to support it (needs spec update,
> either
> > ARM specs or ACPI)
>
> Please see attached slide for the discussion.
>
The attachment got filtered out so send it to me and I will post it on our
website and reply with a link for others to access it.
>
> Thanks
> Hanjun
>
> >
> >
> > [1] Linaro Open Discussions Home
> > <https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home
> >
> > For all open meeting schedules
> > [2] 2020-11-04 Proposed Meeting Agenda
> > <
> https://collaborate.linaro.org/display/LOD/2020-11-04+Proposed+Meeting+Meet…
> >
> >
> > ----------
> > Join Zoom Meeting
> > https://linaro-org.zoom.us/j/98027304997
> >
> > Meeting ID: 980 2730 4997
> > One tap mobile
> > +16699009128,,98027304997# US (San Jose)
> > +12532158782,,98027304997# US (Tacoma)
> >
> > Dial by your location
> > +1 669 900 9128 US (San Jose)
> > +1 253 215 8782 US (Tacoma)
> > +1 301 715 8592 US (Germantown)
> > +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: 980 2730 4997
> > Find your local number: https://linaro-org.zoom.us/u/aehAhwidV2
> >
> --
> 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
>