2024-10-22 Meeting meeting notes

 日期

Oct 22, 2024

 参与者

• @Joyce Qi

• @Jonathan Cameron

• @zengheng4@huawei.com

• @james.morse@arm.com

• @Lorenzo Pieralisi

• @Shameerali Kolothum Thodi

• @Souvik Chakravarty

• @Wei Wu

• @Yushan Wang

• @Dave.Martin@arm.com

 目标

During the meeting, we have talked about two topics: MPAM and Flush by PA range Designs

Zeng Heng has shared the MPAM proposals during the meeting

Open

Recordings:

Video Conferencing, Web Conferencing, Webinars, Screen Sharing

密码： ^y5Q$MKE

 讨论主题

 行动项

• For the MPAM part:

  • Discussion on the handling of L2 MSC in different scenarios:

    • About CPU-idle, only the firmware can know for certain whether the CPU has completed power down,  and software cannot know this information.

    • About CPU hotplug, once the CPU goes offline, the L2 MSC configuration should be reset to default and cleared. 

    • Unless there is a specific user requirement to maintain the L2 configuration, this functionality could be implemented by adding a mount parameter.

    •   Action: The above views need to be talk with Intel/AMD.

  • About Narrow-Partid feature, JM reported that Dave is already attempting to implement this feature. 

    • They hope to achieve this feature while keeping the current user interface stable. It is likely that this goal can be reached by statically allocating reqPartid, which would reduce the friction to merging into the upstream.

    • At the same time, Huawei is also welcome to send self-developed patches for discussion.

    • James shared the code links here after the meeting through email:

      • The code already published for something like the intPARTID proposal is here:
        https://git.gitlab.arm.com/linux-arm/linux-dm/-/commits/mpam/partid-pmg-remap/v0.2/head/?ref_type=heads

        The aim was to keep it within the MPAM driver, initially based on some static configuration to prove its useful before making it more dynamic, probably a mount option.

  • About MPAM bugfix patches, because MPAM driver isn't upstream yet.

    • So he is not really looking for the public mailing list, but still would try to find and check that.

• Flush by PA range Designs discussion:

  • Conclusion:

    • Use the PSCI proposal and a hardware option as test cases.

    • ACPI specification based on a _DSM for a new ACPI00XX device.

    • James can share prototype of the PSCI EL3 code and kernel support.

    • Jonathan to provide a QEMU implementation of the equivalent + prototype AML etc.

    • Kernel side may involve a small subsystem to support DT etc alongside the ACPI00XXX driver.

    • Discoverability interface included – likely to be close to that in the PSCI proposal + some additional support for potential forms of flush.

    Prototype to share + initial spec draft in about 3 weeks, so mid November.

    That should let us discover if the approach is acceptable to kernel community + get initial feedback on ACPI proposal done as code first.

 决策