[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.