Hi Marc,

On 3/20/20 11:05 AM, Marc Zyngier wrote:

Hi Eric,

On 2020-03-20 08:11, Auger Eric wrote:

quoted

Hi Marc,
On 3/4/20 9:33 PM, Marc Zyngier wrote:

quoted

Most of the GICv3 emulation code that deals with SGIs now has to be
aware of the v4.1 capabilities in order to benefit from it.

Add such support, keyed on the interrupt having the hw flag set and
being a SGI.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 virt/kvm/arm/vgic/vgic-mmio-v3.c | 15 +++++-
 virt/kvm/arm/vgic/vgic-mmio.c    | 88 ++++++++++++++++++++++++++++++--
 2 files changed, 96 insertions(+), 7 deletions(-)

[...]

quoted

quoted

@@ -113,7 +125,21 @@ void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,

         struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid +
i);

         raw_spin_lock_irqsave(&irq->irq_lock, flags);
-        if (vgic_irq_is_mapped_level(irq)) {
+        if (irq->hw && vgic_irq_is_sgi(irq->intid)) {
+            if (!irq->enabled) {
+                struct irq_data *data;
+
+                irq->enabled = true;
+                data = &irq_to_desc(irq->host_irq)->irq_data;
+                while (irqd_irq_disabled(data))
+                    enable_irq(irq->host_irq);

could you explain me why the while() is requested?

Ah, interesting question: disable_irq() (and its variants) can nest. This
means that if you have done two disable_irq(), you must do two enable_irq()
to get back to the interrupt being enabled.

The locking should ensure that this nesting doesn't happen, but I'm
paranoid
(see the GICv4.0 doorbell handling). It also makes it easier to reason
about
the initial state.

OK! thank you for this explanation.

Thanks

Eric

[...]

quoted

Reviewed-by: Eric Auger <eric.auger@redhat.com>

Thanks!

         M.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel