Re: [Xen-devel] [PATCH 2/4] xen/arm: gic: Ensure ordering between read of INTACK and shared data

[Andrii Anisov <Andrii_Anisov@xxxxxxxx>]

On 23.10.18 21:17, Julien Grall wrote:
> When an IPI is generated by a CPU, the pattern looks roughly like:
>
>    <write shared data>
>    dsb(sy);
>    <write to GIC to signal SGI>
>
> On the receiving CPU we rely on the fact that, once we've taken the
> interrupt, then the freshly written shared data must be visible to us.
> Put another way, the CPU isn't going to speculate taking an interrupt.
>
> Unfortunately, this assumption turns out to be broken.
>
> Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
> to read some shared_data. Before CPUx has done anything, a random
> peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
> CPUy then takes the IRQ and starts executing the entry code, heading
> towards gic_handle_irq. Furthermore, let's assume that a bunch of the
> previous interrupts handled by CPUy were SGIs, so the branch predictor
> kicks in and speculates that irqnr will be <16 and we're likely to
> head into handle_IPI. The prefetcher then grabs a speculative copy of
> shared_data which contains a stale value.
>
> Meanwhile, CPUx gets round to updating shared_data and asking the GIC
> to send an SGI to CPUy. Internally, the GIC decides that the SGI is
> more important than the peripheral interrupt (which hasn't yet been
> ACKed) but doesn't need to do anything to CPUy, because the IRQ line
> is already raised.
>
> CPUy then reads the ACK register on the GIC, sees the SGI value which
> confirms the branch prediction and we end up with a stale shared_data
> value.
>
> This patch fixes the problem by adding an smp_rmb() to the IPI entry
> code in do_SGI.
>
> At the same time document the write barrier.
>
> Based on Linux commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496
> "irqchip/gic: Ensure ordering between read of INTACK and shared data".
>
> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
>
> ---
>      This patch is candidate for backporting up to Xen 4.9.
> ---

Reviewed-by: Andrii Anisov <andrii_anisov@xxxxxxxx>
-- 

*Andrii Anisov*



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel