On 21:36-20180613, Florian Fainelli wrote: [...] > >>> c) This workaround applies to only the boot processor. It is important > >>> to apply workaround as necessary (context-save-restore) around low > >>> power context loss OR additional processors as necessary in either > >>> firmware support OR elsewhere in OS. > >> > >> About that, I don't know enough of uboot but are there existing PSCI or > >> other seemingly standard secondary core support in uboot that would make > >> us go through the same initialization as the boot CPU? If not, is > >> everything going to be largely implementation specific and > >> scattered between uboot and the hypervisors or kernel? > > > > in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard. > > even within TI, Few of the SoCs use PSCI, others did implement custom > > SMC calls (since they existed in an architecture prior to PSCI). > > > >> > >> FWIW, this is what prompted me to submit this: > >> > >> https://patchwork.kernel.org/patch/10453643/ > > > > That wont work in a generic manner for precisely the same reason I had to do > > it with weak function in u-boot (some SoCs will only permit 'mcr > > p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc > > call to make it happen). Unfortunately, IMHO, at least at this > > point, there'd be custom implementations per SoC and layers depending on > > where to implement it. > > It won't work in a generic manner but it will work for some platforms > where updating the firmware is impractical, and since the bits are write > ignore if your PL does not allow it, this still seems like a net win for > platforms where this is effective, and it does take care of Linux doing > the SMP bring-up of secondary cores as well. That's what we have in our > downstream tree at least, and I was hoping this could land upstream too.
I think it is clear from Russell's summary that we dont want "may work" workaround in kernel/bootloaders. in case of u-boot (which this patch is about), I'd suggest adding the CONFIG_*CVE* input to the Kconfig for the SoC where you know for sure this works. Does that sound a fair tradeoff? -- Regards, Nishanth Menon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot