Re: [Xen-devel] [query] gic_set_lr always uses maintenance Interrupt

[Mj Embd <mj.embd@xxxxxxxxx>]

A few thoughts are circling around my mind, don't know how much
interrupt latency would it have.

Rather than the hypervisor entry when guest does EOI, a late / lazy
checkin on LR's can be done
 on next hypervisor entry by
a) guest doing something and trapping to hypervisor
b) schedular timer in hypervisor

What do you think on this...

On Wed, Nov 6, 2013 at 11:54 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 31 Oct 2013, Mj Embd wrote:
>> On Thu, Oct 31, 2013 at 9:13 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> wrote:
>> > On Wed, 2013-10-30 at 15:08 +0530, Mj Embd wrote:
>> >> Hi,
>> >>
>> >> As per section 5.2.2 of IHI0048B_b_gic_architecture_specification, If
>> >> hypervisor is injecting a VIRQ into guest, that is actually a HW IRQ,
>> >
>> > Is it? You mean LR.HW is set? AIUI this means the IRQ is an actual
>> > hardware IRQ which is passed through, whereas the VIRQs are entirely
>> > fictional virtual interrupts. (or maybe you mean some other sort of
>> > VIRQ?)
>> >
>>
>> If say a timer HW interrupt is injected into guest. And if guest does
>> EOI, the HW interrupt is deactivated.
>> This is an optimisation as per ARM which saves a trap to hypervisor
>> which is in form of a maintenance interrupt.
>>
>> I see in the code gic_set_lr always chooses an option for maintenance
>> interrupt. So it is not using ARM's optimisation technique.
>>
>> The reason I thought why this is done is bcase problem I see with this
>> is that hypervisor still has its LR used and has no way of determining
>> when it can replenish LR for further interrupts to be injected in
>> guest. But I could be wrong, why would ARM provide a way an keep a
>> loophole
>
> Your analysis is correct. Even if the hardware interrupt is deactivated
> how can Xen know exactly which LRs need to be cleared and when?
>
> If you can figure out the answer to these questions we might be able to
> start avoiding maintenance interrupts on hardware interrupts :)



-- 
-mj

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel