If a guest disables an LPI, we do not forward this to the associated
host LPI to avoid queueing commands to the host ITS command queue.
So it may happen that an LPI fires nevertheless on the host. In this
case we can bail out early, but have to save the pending state on the
virtual side. We do this by storing the pending bit in struct
pending_irq, which is assiociated with mapped LPIs.
Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
---
xen/arch/arm/gic-v3-lpi.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d8baebc..7d20986 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -136,6 +136,22 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool
use_pta)
return per_cpu(lpi_redist, cpu).redist_id << 16;
}
+static bool vgic_can_inject_lpi(struct vcpu *vcpu, uint32_t vlpi)
+{
+ struct pending_irq *p;
+
+ p = vcpu->domain->arch.vgic.handler->lpi_to_pending(vcpu->domain, vlpi);
+ if ( !p )
+ return false;
+
+ if ( test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) )
+ return true;
+
+ set_bit(GIC_IRQ_GUEST_LPI_PENDING, &p->status);
+
+ return false;
+}
+
/*
* Handle incoming LPIs, which are a bit special, because they are potentially
* numerous and also only get injected into guests. Treat them specially here,
@@ -187,7 +203,15 @@ void gicv3_do_LPI(unsigned int lpi)
/* Check if the VCPU is ready to receive LPIs. */
if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
- vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+ {
+ /*
+ * We keep all host LPIs enabled, so check if it's disabled on the
+ * guest side and just record this LPI in the virtual pending table
+ * in this case. The guest picks it up once it gets enabled again.
+ */
+ if ( vgic_can_inject_lpi(vcpu, hlpi.virt_lpi) )
+ vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+ }
rcu_unlock_domain(d);
}
--
2.8.2
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
