Hi Rob, On 31/03/2023 14:46, Rob Herring wrote: > On Thu, Mar 30, 2023 at 11:52 AM James Morse <james.morse@xxxxxxx> wrote: >> The Errata Management SMCCC interface allows firmware to advertise whether >> the OS is affected by an erratum, or if a higher exception level has >> mitigated the issue. This allows properties of the device that are not >> discoverable by the OS to be described. e.g. some errata depend on the >> behaviour of the interconnect, which is not visible to the OS. >> >> Deployed devices may find it significantly harder to update EL3 >> firmware than the device tree. Erratum workarounds typically have to >> fail safe, and assume the platform is affected putting correctness >> above performance. > > Updating the DT is still harder than updating the kernel. A well > designed binding allows for errata fixes without DT changes. That > generally means specific compatibles up front rather than adding > properties to turn things on/off. I started with a per-erratum identifier, but there are 8 of them, and its hard to know where to put it. The CPU side is detectable from the MIDR,its an interconnect property that we need to know ... but the interconnect isn't described in the DT. (but the obvious compatible string identifies the PMU) > Do we really want to encourage/endorse/support non-updatable firmware? > We've rejected plenty of things with 'fix your firmware'. A DT property was explicitly requested by Marc Z on the RFC: https://lore.kernel.org/linux-arm-kernel/86mt5dxxbc.wl-maz@xxxxxxxxxx/ The concern is that platforms where the CPU is affected, but the issue is masked by the interconnect will never bother with a firmware interface. The kernel can't know this, so has to enable the workaround at the cost of performance. Adding a DT property to describe the hardware state of the erratum avoids the need for separate kernel builds to work around the missing firmware. >> Instead of adding a device-tree entry for any CPU errata that is >> relevant (or not) to the platform, allow the device-tree to describe >> firmware's responses for the SMCCC interface. This could be used as >> the data source for the firmware interface, or be parsed by the OS if >> the firmware interface is missing. > What's to prevent vendors from only using the DT mechanism and never > supporting the SMCCC interface? I'm sure some will love to not have to > make a firmware update when they can just fix it in DT. The firmware interface has to exist for ACPI systems where EL3 can't influence the ACPI tables, which typically get replaced if the part is OEM'd. Ultimately all the interface is describing is a non-discoverable hardware property relevant to an erratum. These are often configurations the silicon manufacturer chooses. In this case its the behaviour of the interconnect. If we didn't have to support ACPI systems, this stuff would only have been in the DT. With > The downside to this extendable binding compared to simple properties > is parsing a flat tree is slow and more complicated. So it may be > difficult to support if you need this early in boot. I do need this early in the boot, but I'm not worried about the delay as these tables should be small. >> Most errata can be detected from CPU id registers. These mechanisms >> are only needed for the rare cases that external knowledge is needed. > > And also have significant performance impact. In the end, how many > platforms are there that can't fix these in firmware and need a > mainline/distro kernel optimized to avoid the work-around. I suspect > the number is small enough it could be a list in the kernel. At a guess, its all mobile phones produced in the last 2 years that want to run a version of Android that uses virtualisation. Cortex-A78 is affected, but I don't know when the first products were shipped. Thanks, James
