On 2/9/21 2:33 PM, Lorenzo Pieralisi wrote:

quoted

Do we need a similar fix for TFSRE0_EL1? We get away with this if
suspend is only entered on the idle (kernel) thread but I recall we
could also enter suspend on behalf of a user process (I may be wrong
though).

Yes, when we suspend the machine to RAM, we execute suspend on behalf
on a userspace process (but that's only running on 1 cpu, the others
are hotplugged out).

IIUC (and that's an if) TFSRE0_EL1 is checked on kernel entry so I don't
think there is a need to save/restore it (just reset it on suspend
exit).

TFSR_EL1, I don't see a point in saving/restoring it (it is a bit
per-CPU AFAICS) either, IMO we should "check" it on suspend (if it is
possible in that context) and reset it on resume.

I don't think though you can "check" with IRQs disabled so I suspect
that TFSR_EL1 has to be saved/restored (which means that there is a
black out period where we run kernel code without being able to detect
faults but there is no solution to that other than delaying saving the
value to just before calling into PSCI). Likewise on resume from low
power.

Ok, based on what you are saying it seems that the most viable solution here is
to save and restore TFSR_EL1. I will update my code accordingly.

Thanks,
Lorenzo

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel