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

Re: [Xen-devel] [PATCH v3 5/6] vpt: add support for level interrupts



>>> On 22.06.18 at 17:24, <roger.pau@xxxxxxxxxx> wrote:
> On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
>> >>> On 08.06.18 at 17:07, <roger.pau@xxxxxxxxxx> wrote:
>> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
>> >          if ( pt->pending_intr_nr )
>> >          {
>> >              /* RTC code takes care of disabling the timer itself. */
>> > -            if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) )
>> > +            if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) &&
>> > +                 /* Level interrupts should be asserted even if masked. */
>> > +                 !pt->level )
>> >              {
>> >                  /* suspend timer emulation */
>> 
>> Especially with this comment I'm not convinced this change is fully
>> correct: Once a level triggered interrupt is latched in IRR, no
>> further assertions are meaningful, and hence emulation could (and
>> hence should) still be stopped to reduce resource consumption.
> 
> Hm, I can see your point, but that's going to make the implementation
> of HPET level trigger interrupts more complex.
> 
> From my reading of the spec, when a level triggered HPET interrupt
> fires the ISR bit must be set, regardless of whether the IRR of the
> io-apic entry is set or not.
> 
> Maybe the right solution is to add a pt_irq_pending that checks the
> IRR bit, and a new flag that the caller can set in order to requests
> callbacks regardless of whether the interrupt has been injected or
> not. Would you agree to that plan?

That sounds like a reasonable option. Another would be to add a
parameter to the callback allowing the context to be identified to the
callee.

Jan



_______________________________________________
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®.