> > > > > Regarding RASF patrol scrub no one cared about it as it's useless and > > > > any new implementation should be RAS2. > > > > > > The assertion that "RASF patrol scrub no one cared about it as it's > > > useless and any new implementation should be RAS2" needs evidence. > > > > > > For example, what platforms are going to ship with RAS2 support, what > > > are the implications of Linux not having RAS2 scrub support in a month, > > > or in year? There are parts of the ACPI spec that have never been > > > implemented what is the evidence that RAS2 is not going to suffer the > > > same fate as RASF? > > > > From discussions with various firmware folk we have a chicken and egg > > situation on RAS2. They will stick to their custom solutions unless there is > > plausible support in Linux for it - so right now it's a question mark > > on roadmaps. Trying to get rid of that question mark is why Shiju and I > > started looking at this in the first place. To get rid of that question > > mark we don't necessarily need to have it upstream, but we do need > > to be able to make the argument that there will be a solution ready > > soon after they release the BIOS image. (Some distros will take years > > to catch up though). > > > > If anyone else an speak up on this point please do. Discussions and > > feedback communicated to Shiju and I off list aren't going to > > convince people :( > > Negatives perhaps easier to give than positives given this is seen as > > a potential feature for future platforms so may be confidential. > > So one of the observations from efforts like RAS API [1] is that CXL is > definining mechanisms that others are using for non-CXL use cases. I.e. > a CXL-like mailbox that supports events is a generic transport that can > be used for many RAS scenarios not just CXL endpoints. It supplants > building new ACPI interfaces for these things because the expectation is > that an OS just repurposes its CXL Type-3 infrastructure to also drive > event collection for RAS API compliant devices in the topology. > > [1]: https://www.opencompute.org/w/index.php?title=RAS_API_Workstream > > So when considering whether Linux should build support for ACPI RASF, > ACPI RAS2, and / or Open Compute RAS API it is worthwile to ask if one > of those can supplant the others. RAS API is certainly interesting but the bit of the discussion that matters here will equally apply to CXL RAS controls as of today (will ship before OCP) and Open Compute's RAS API (sometime in the future). The subsystem presented here was to address the "show us your code" that was inevitable feedback if we'd gone for a discussion Doc style RFC. What really matters here is whether a common ABI is necessary and what it looks like. Not even the infrastructure, just whether it's sysfs and what the controls) Sure there is less code if it all looks like that CXL get feature, but not that much less. + I'm hoping we'll also end up sharing with the various embedded device solutions out there today. I notice a few familiar names in the meeting recordings. Anyone want to provide a summary of overlap etc and likely end result? I scan read the docs and caught up with some meetings at high speed, but that's not the same as day to day involvement in the spec development. Maybe the lesson to take away from this is a more general interface is needed incorporating scrub control (which at this stage is probably just a name change!) I see that patrol scrub is on the RAS actions list which is great. > > Speaking only for myself with my Linux kernel maintainer hat on, I am > much more attracted to proposals like RAS API where native drivers can > be deployed vs ACPI which brings ACPI static definition baggage and a > 3rd component to manage. RAS API is kernel driver + device-firmware > while I assume ACPI RAS* is kernel ACPI driver + BIOS firmware + > device-firmware. Not really. The only thing needed from BIOS firmware is a static table to OS to describe where to find the hardware (RAS2 is a header and (1+) pointers to the PCCT table entry that tells you where the mailbox(s) (PCC Channel) are and their interrupts etc. It's all of 48 bytes of static data to parse. Could have been done that in DSDT (where you will find other PCC channels as many methods can use them under the hood to chat to firmware + there are some other users where they are the only option) but my guess is assumption is RAS might be needed pre AML interpreter so it's a static table. A PCC channel is the ACPI spec standard mailbox design (well several options for how to do it, but given the code is upstream and in use for other purposes, no new maintenance burden for us :) PCC channels can be shared resources handling multiple protocols. They are used for various other things where the OS needs to talk to firmware and have been upstream for a while. ACPI driver --------<PCC Mailbox>---> Device Firmware vs RAS API Driver-----<CXL Mailbox>----> Device Firmware or CXL Driver --------<CXL Mailbox>----> Device Firmware The new complexity (much like the CXL solution) lies in the control protocol sent over the mailbox (which is pretty simple!) Some of the complexity in the driver is left over from earlier version doing RASF and RAS2 so we'll flatten that layering out and it'll be even simpler in next RFC and perhaps not hint at false complexity or maintenance burden. The only significant burden I really see form incorporating RAS2 is the need for an interface that works for both (very similar) configuration control sets. Once that is defined we need to support the ABI for ever anyway so may be sysfs attribute of extra ABI to support in current design? > > In other words, this patch proposal enables both CXL memscrub and ACPI > RAS2 memscrub. It asserts that nobody cares about ACPI RASF memscrub, > and your clarification asserts that RAS2 is basically dead until Linux > adopts it. So then the question becomes why should Linux breath air into > the ACPI RAS2 memscrub proposal when initiatives like RAS API exist? A fair question and one where I'm looking for inputs from others. However I think you may be assuming a lot more than is actually involved in the RAS2 approach - see below. > > The RAS API example seems to indicate that one way to get scrub support > for non-CXL memory controllers would be to reuse CXL memscrub > infrastructure. In a world where there is kernel mechanism to understand > CXL-like scrub mechanisms, why not nudge the industry in that direction > instead of continuing to build new and different ACPI mechanisms? There may be some shared elements of course (and it seems the RAS API stuff has severak sets of proposals for interfacing approaches), but ultimately a RAS API element still hangs off something that isn't a CXL device, so still demands some common infrastructure (e.g. a class or similar) or we are going to find the RAS tools buried under a bunch of different individual drivers. 1) Maybe shared for system components (maybe not from some of the diagrams!) But likely 1 interface per socket. Probably PCI, but maybe platform devices (I'd not be surprised to see a PCC channel type added for this mailbox) /sys/bus/pci/devices/pcixxx/rasstuff/etc 2) CXL devices say /sys/bus/cxl/devices/mem0/rasstuff/etc. 3) Other system components such as random PCI drivers. Like other cases of common infrastructure, I'd argue for a nice class with the devices parentage linking back to the underlying EP driver. /sys/class/ras/ras0 parent -> /sys/bus/cxl/devices/mem0/ /sys/class/ras/ras1 parent -> /sys/bus/pci/device/pcixxx/ RAS API device. etc Same as if we had a bunch of devices that happened to have an LED on them and wanted common userspace controls so registered with /sys/class/led So to me RAS API looks like another user of this proposal that indeed shares a bunch of common code with the CXL driver stack (hopefully they'll move to PCI MMPT from current definition based on CXL 2.0 mailbox so the discoverability isn't CXL spec based. (I may not have latest version of course!) > > > > There are parts of the CXL specification that have > > > never been implemented in mass market products. > > > > Obviously can't talk about who was involved in this feature > > in it's definition, but I have strong confidence it will get implemented > > for reasons I can point at on a public list. > > a) There will be scrubbing on devices. > > b) It will need control (evidence for this is the BIOS controls mentioned below > > for equivalent main memory). > > c) Hotplug means that control must be done by OS driver (or via very fiddly > > pre hotplug hacks that I think we can all agree should not be necessary > > and aren't even an option on all platforms) > > d) No one likes custom solutions. > > This isn't a fancy feature with a high level of complexity which helps. > > That does help, it would help even more if the maintenance burden of CXL > scrub precludes needing to carry the burden of other implementations. I think we disagree on whether the burden is significant - sure we can spin interfaces differently to make it easier for CXL and we can just stick it on the individual endpoints for now. Key here is ABI, I don't really care about whether we wrap it up in a subsystem (mostly we do that to enforce compliance with the ABI design as easier than reviewing against a document!) I want to see userspace ABI that is general enough to extend to other devices and doesn't require a horrible hydra of a userspace program on top of incompatible controls because everyone wanted to do it slightly differently. The exercise of including RAS2 (and earlier RASF which we dropped) was about establishing commonality and I think that was very useful. I'm reluctant to say it will never be necessary to support RAS2 (because I want to see solutions well before anyone will have built OCPs proposal and RAS2 works on many of today's systems with a small amount of firmware work, many have existing PCC channels to appropriate management controllers and as I understand it non standard interfaces to control the scrubbing engines). So I think not considering an ABI that is designed to be general is just storing up pain for us in the future. I'm not sure the design we have here is the right one which is why it was an RFC :) > > [..] > > > > > > > Previous discussions in the community about RASF and scrub could be find here. > > > > https://lore.kernel.org/lkml/20230915172818.761-1-shiju.jose@xxxxxxxxxx/#r > > > > and some old ones, > > > > https://patchwork.kernel.org/project/linux-arm-kernel/patch/CS1PR84MB0038718F49DBC0FF03919E1184390@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > > > > > Do not make people hunt for old discussions, if there are useful points > > > in that discussion that make the case for the patch set include those in > > > the next submission, don't make people hunt for the latest state of the > > > story. > > > > Sure, more of an essay needed along with links given we are talking > > about the views of others. > > > > Quick summary from a reread of the linked threads. > > AMD not implemented RASF/RAS2 yet - looking at it last year, but worried > > about inflexibility of RAS2 spec today. They were looking at some spec > > changes to improve this + other functions to be added to RAS2. > > I agree with it being limited, but think extending with backwards > > compatibility isn't a problem (and ACPI spec rules in theory guarantee > > it won't break). I'm keen on working with current version > > so that we can ensure the ABI design for CXL encompasses it. > > > > Intel folk were cc'd but not said anything on that thread, but Tony Luck > > did comment in Jiaqi Yan's software scrubbing discussion linked below. > > He observed that a hardware implementation can be complex if doing range > > based scrubbing due to interleave etc. RAS2 and CXL both side step this > > somewhat by making it someone elses problem. In RAS2 the firmware gets > > to program multiple scrubbers to cover the range requested. In CXL > > for now this leaves the problem for userspace, but we can definitely > > consider a region interface if it makes sense. > > > > I'd also like to see inputs from a wider range of systems folk + other > > CPU companies. How easy this is to implement is heavily dependent on > > what entity in your system is responsible for this sort of runtime > > service and that varies a lot. > > This answers my main question of whether RAS2 is a done deal with > shipping platforms making it awkward for Linux to *not* support RAS2, or > if this is the start of an industry conversation that wants some Linux > ecosystem feedback. It sounds more like the latter. I'll let others speak up on this as I was presenting on my current outlook and understand others are much further down the path. > > > > > https://lore.kernel.org/all/20221103155029.2451105-1-jiaqiyan@xxxxxxxxxx/ > > > > > > Yes, now that is a useful changelog, thank you for highlighting it, > > > please follow its example. > > > > It's not a changelog as such but a RFC in text only form. > > However indeed lots of good info in there. > > > > Jonathan > > Thanks again for taking the time Jonathan. > You are welcome and thanks for all the questions / pointers. Jonathan
