On 2020-08-21 13:26, Catalin Marinas wrote:

On Fri, Aug 21, 2020 at 01:12:10PM +0100, Will Deacon wrote:

quoted

On Fri, Aug 21, 2020 at 01:07:00PM +0100, Catalin Marinas wrote:

quoted

On Mon, Aug 03, 2020 at 01:31:27PM -0600, Rob Herring wrote:

quoted

@@ -979,6 +980,14 @@
 		write_sysreg(__scs_new, sysreg);			\
 } while (0)

+#define read_sysreg_par() ({						\
+	u64 par;							\
+	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
+	par = read_sysreg(par_el1);					\
+	asm(ALTERNATIVE("nop", "dmb sy", ARM64_WORKAROUND_1508412));	\
+	par;								\
+})

I was about to queue this up but one more point to clarify: can we get
an interrupt at either side of the PAR_EL1 read and the handler do a
device read, triggering the erratum? Do we need a DMB at exception
entry/return?

Disabling irqs around the PAR access would be simpler, I think 
(assuming
this is needed).

This wouldn't work if it interrupts a guest.

If we take an interrupt either side of the PAR_EL1 read and that we
fully exit, the saving of PAR_EL1 on the way out solves the problem.

If we don't fully exit, but instead reenter the guest immediately
(fixup_guest_exit() returns true), we'd need a DMB at that point,
at least because of the GICv2 proxying code which performs device
accesses on the guest's behalf.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

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