Re: [Xen-devel] [RFC 01/16] xen/arm: Re-enable interrupt later in the trap path

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

Hello Julien,

It looks I missed answering this email. So do this now:

On 29.11.18 00:00, Julien Grall wrote:
> On 28/11/2018 21:31, Andrii Anisov wrote:
> > From: Julien Grall <julien.grall@xxxxxxx>
> >
> > This makes function enter_hypervisor_head() being executed with
> > irqs locked. This also give a fine side effect - it assures that
> > LRs are cleared prior to any IRQs processing, which leads to a
> > better (faster) IRQs processing.
> Again, this need some rationale why is it faster. And how this is going
> to impact the other vGIC...
With the current code, there is a chance that hypervisor performs do_IRQ() 
before fetching LRs with the information about IRQs being processed by a guest. 
This could happen in guest trap paths where interrupts are enabled before 
`enter_hypervisor_head()` call.

Performing `do_IRQ()` prior to `vgic_sync_from_lrs()` is assumed as less 
efficient than doing it vice versa for high IRQ rate use-cases with the number 
of different interrupts (specific for multimedia scenarios).

 - For the old vgic implementation, `vgic_sync_from_lrs()` release LRs from 
processed interrupts also shortens `inflight_irqs` sorted list. So `do_IRQ()` 
has better chances to write IRQ directly to LR instead of saving it into 
`lr_pending` list and possibly faster insert the new IRQ into `inflight_irqs` 
list.

 - For the new vgic implementation, `vgic_sync_from_lrs()` fetches about 
processed interrupts from LRs and shortens `ap_list`. So `do_IRQ()` could 
potentially faster insert the new interrupt into `ap_list`.


--
Sincerely,
Andrii Anisov.
.

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