Hi James, On Thu, Mar 30, 2023 at 05:51:22PM +0100, James Morse wrote: > Changes since the RFC?: > * Added DT support, in a way that means we don't end up with per-erratum > strings, or bloat in the calling code to check for those strings. > * Added a commandline argument. (boo) > * Changes to support errata affecting features on big-little systems properly. > > ~ > > When stage1 translation is disabled, the SCTRL_E1.I bit controls the > attributes used for instruction fetch, one of the options results in a > non-cacheable access. A whole host of CPUs missed the FWB override > in this case, meaning a KVM guest could fetch stale/junk data instead of > instructions. > > The workaround is to disable FWB, and do the required cache maintenance > instead. > > The good news is, this isn't a problem for systems using Arm's > interconnect IP. The bad news is: linux can't know this. Arm knows of > at least one platform that is affected by this erratum. > > > This series adds support for the 'Errata Management Firmware Interface', [0] > and queries that to determine if the CPU is affected or not. DT support is > added so that the firmware interface values can be queried directly from the > DT. This can be used as a fallback for platforms that don't yet support the > interface. It occurs to me that, when a device is assigned to a VM, there are a whole bunch of non-probeable reasons why FWB cannot be used and perhaps we should be looking to advertise that from firmware without pulling in a reliance on this errata management interface. Right now, I don't think KVM or VFIO do anything to prevent the assignment of a device capable of non-coherent DMA traffic and FWB is used if the CPUs support it. This, in theory, allows the guest to read stale data from host memory pages using non-coherent DMA and I think we should gate usage of FWB for a given VM on whether or not that VM has such a device assigned. The problem is that I don't think you can probe this property reliably. It's not enough to check for "dma-coherent"; rather we also need to know details about the IOMMU and device-specific properties such as the ability to generate NoSnoop transactions. I think firmware is probably the only option here, so since you're proposing something similar, please can we make it general enough to be used outside of errata scenarios? Will
