On 2020-08-21 13:26, Catalin Marinas wrote:
On Fri, Aug 21, 2020 at 01:12:10PM +0100, Will Deacon wrote:
On Fri, Aug 21, 2020 at 01:07:00PM +0100, Catalin Marinas wrote:
> On Mon, Aug 03, 2020 at 01:31:27PM -0600, Rob Herring wrote:
> > @@ -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...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
