On Sat 23 Feb 10:37 PST 2019, Marc Zyngier wrote: > On Sat, 23 Feb 2019 18:12:54 +0000, > Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > > > On Mon 11 Feb 06:59 PST 2019, Marc Zyngier wrote: > > > > > On 11/02/2019 14:29, AngeloGioacchino Del Regno wrote: > > > > > > [...] > > > > > > > Also, just one more thing: yes this thing is going ARM64-wide and > > > > - from my findings - it's targeting certain Qualcomm SoCs, but... > > > > I'm not sure that only QC is affected by that, others may as well > > > > have the same stupid bug. > > > > > > > > > > At the moment, only QC SoCs seem to be affected, probably because > > > everyone else has debugged their hypervisor (or most likely doesn't > > > bother with shipping one). > > > > > > In all honesty, we need some information from QC here: which SoCs are > > > affected, what is the exact nature of the bug, can it be triggered from > > > EL0. Randomly papering over symptoms is not something I really like > > > doing, and is likely to generate problems on unaffected systems. > > > > > > > The bug at hand is that the XZR is not deemed a valid source in the > > virtualization of the SMMU registers. It was identified and fixed for > > all platforms that are shipping kernels based on v4.9 or later. > > When you say "fixed": Do you mean fixed in the firmware? Or by adding > a workaround in the shipped kernel? I mean that it's fixed in the firmware. > If the former, is this part of an official QC statement, with an > associated erratum number? I don't know, will get back to you on this one. > Is this really limited to the SMMU accesses? > Yes. > > As such Angelo's list of affected platforms covers the high-profile > > ones. In particular MSM8996 and MSM8998 is getting pretty good support > > upstream, if we can figure out a way around this issue. > > We'd need an exhaustive list of the affected SoCs, and work out if we > can limit the hack to the SMMU driver (cc'ing Robin, who's the one > who'd know about it). > I will try to compose a list. Regards, Bjorn
