On Fri, Dec 17, 2021 at 10:57 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > Hi Rob, > > On 2021-12-16 23:31, Rob Herring wrote: > > Use the minimum CPU h/w id of the CPUs associated with the cache for the > > cache 'id'. This will provide a stable id value for a given system. As > > we need to check all possible CPUs, we can't use the shared_cpu_map > > which is just online CPUs. There's not a cache to CPUs mapping in DT, so > > we have to walk all CPU nodes and then walk cache levels. > > I believe another expected use of the cache ID exposed in sysfs is to > program steering tags for cache stashing (typically in VFIO-based > userspace drivers like DPDK so we can't realistically mediate it any > other way). There were plans afoot last year to ensure that ACPI PPTT > could provide the necessary ID values for arm64 systems which will > typically be fairly arbitrary (but unique) due to reflecting underlying > interconnect routing IDs. Assuming that there will eventually be some > interest in cache stashing on DT-based systems too, we probably want to > allow for an explicit ID property on DT cache nodes in a similar manner. If you have a suggestion for ID values that correspond to the h/w, then we can add them. I'd like a bit more than just trusting that ID is something real. While the ACPI folks may be willing to take an arbitrary index, it's something we (mostly) avoid for DT. > That said, I think it does make sense to have some kind of > auto-generated fallback scheme *as well*, since I'm sure there will be > plenty systems which care about MPAM but don't support stashing, and > therefore wouldn't have a meaningful set of IDs to populate their DT > with. Conversely I think that might also matter for ACPI too - one point > I remember from previous discussions is that PPTT may use a compact > representation where a single entry represents all equivalent caches at > that level, so I'm not sure we can necessarily rely on IDs out of that > path being unique either. AIUI, cache ids break the compact representation. Rob
