Hi Marc, On Fri, Sep 24, 2021 at 09:25:39AM +0100, Marc Zyngier wrote: > The infamous M1 has a feature nobody else ever implemented, > in the form of the "GIC locally generated SError interrupts", > also known as SEIS for short. > > These SErrors are generated when a guest does something that violates > the GIC state machine. It would have been simpler to just *ignore* > the damned thing, but that's not what this HW does. Oh well. > > This part of of the architecture is also amazingly under-specified. > There is a whole 10 lines that describe the feature in a spec that > is 930 pages long, and some of these lines are factually wrong. > Oh, and it is deprecated, so the insentive to clarify it is low. > > Now, the spec says that this should be a *virtual* SError when > HCR_EL2.AMO is set. As it turns out, that's not always the case > on this CPU, and the SError sometimes fires on the host as a > physical SError. Goodbye, cruel world. This clearly is a HW bug, > and it means that a guest can easily take the host down, on demand. > > Thankfully, we have seen systems that were just as broken in the > past, and we have the perfect vaccine for it. > > Apple M1, please meet the Cavium ThunderX workaround. All your > GIC accesses will be trapped, sanitised, and emulated. Only the > signalling aspect of the HW will be used. It won't be super speedy, > but it will at least be safe. You're most welcome. > > Given that this has only ever been seen on this single implementation, > that the spec is unclear at best and that we cannot trust it to ever > be implemented correctly, gate the workaround solely on ICH_VTR_EL2.SEIS > being set. > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> [...] I reproduced this issue on my M1 by using kvmtool and EDKII [1], and have confirmed that this fixes it. Tested-by: Joey Gouly <joey.gouly@xxxxxxx> Thanks, Joey [1] It is fixed in EDKII now, but I reverted Ard's EDKII commit locally: a82bad9730178a1e3a67c9bfc83412b87a8ad734
