Hi,
On 08/06/17 10:45, Julien Grall wrote:
> Hi Andre,
>
> On 26/05/17 18:35, Andre Przywara wrote:
>> +/*
>> + * Find an unused LR to insert an IRQ into, starting with the LR given
>> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other
>> LRs to
>> + * avoid inserting the same
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
+ * avoid inserting the same IRQ twice. This situation can occur when an
+ * event gets
On Fri, 2 Jun 2017, Julien Grall wrote:
> Hi Andre,
>
> On 05/26/2017 06:35 PM, Andre Przywara wrote:
> > @@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned
> > int virtual_irq)
> > #endif
> > }
> > +/*
> > + * Find an unused LR to insert an IRQ into, starting with
Hi Andre,
On 05/26/2017 06:35 PM, Andre Przywara wrote:
@@ -441,6 +443,40 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int
virtual_irq)
#endif
}
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI,
When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same
