Re: [Xen-devel] [RFC v2 00/16] Old GIC (gic-vgic) optimizations for GICV2

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 02/01/2019 18:33, André Przywara wrote:
> On 26/12/2018 11:20, Andrii Anisov wrote:
> Then I looked at the IRQ handler and stumbled upon the function pointers
> we are using. I was eyeing them before, because my hunch is they are
> costly, especially on big cores, as it might be hard for the CPU to
> speculate correctly. Basically something like a call to
> gic_hw_ops->gic_read_irq() translates into:
>         ldr     x0, [x20]
>         ldr     x0, [x0, #72]
>         blr     x0
> That contains two dependency on loads. If one of them misses in the
> cache, the whole pipeline is stalled, if the CPU doesn't speculate both
> loads correctly (which it might, but we don't know).
> This is extra annoying since those function pointers never change, and
> are always pointing to the GICv2 functions if CONFIG_GICV3 is not
> defined. On top of this some functions are really trivial, so we pay a
> big price for something that might be a single MMIO read or even system
> register access. I think the proper solution (TM) would be to patch
> these accesses once we know which GIC we are running on. Linux does
> something to this effect, which benefits GICv3 in particular. From
> quickly looking at it, Xen seems to lack the infrastructure (jump labels
> and more sophisticated runtime patching) to easily copy this method.
The x86 folks are looking at reducing the overhead for call (see [1]).

We could implement similar framework for patching the GIC call.

Cheers,

[1]     <5B97C3D402000078001E747C@xxxxxxxxxxxxxxxxxxxxxxxx>

--
Julien Grall

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