|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 20/39] ARM: new VGIC: Add PENDING registers handlers
On Wed, 21 Mar 2018, Andre Przywara wrote:
> The pending register handlers are shared between the v2 and v3
> emulation, so their implementation goes into vgic-mmio.c, to be easily
> referenced from the v3 emulation as well later.
> For level triggered interrupts the real line level is unaffected by
> this write, so we keep this state separate and combine it with the
> device's level to get the actual pending state.
> Hardware mapped IRQs need some special handling, as their hardware state
> has to be coordinated with the virtual pending bit to avoid hanging
> or masked interrupts.
>
> This is based on Linux commit 96b298000db4, written by Andre Przywara.
>
> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
> Reviewed-by: Julien Grall <julien.grall@xxxxxxx>
> ---
> xen/arch/arm/vgic/vgic-mmio-v2.c | 4 +-
> xen/arch/arm/vgic/vgic-mmio.c | 125
> +++++++++++++++++++++++++++++++++++++++
> xen/arch/arm/vgic/vgic-mmio.h | 11 ++++
> 3 files changed, 138 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c
> b/xen/arch/arm/vgic/vgic-mmio-v2.c
> index 7efd1c4eb4..a48c554040 100644
> --- a/xen/arch/arm/vgic/vgic-mmio-v2.c
> +++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
> @@ -95,10 +95,10 @@ static const struct vgic_register_region
> vgic_v2_dist_registers[] = {
> vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_spending, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICPENDR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
> vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
> index f219b7c509..53b8978c02 100644
> --- a/xen/arch/arm/vgic/vgic-mmio.c
> +++ b/xen/arch/arm/vgic/vgic-mmio.c
> @@ -156,6 +156,131 @@ void vgic_mmio_write_cenable(struct vcpu *vcpu,
> }
> }
>
> +unsigned long vgic_mmio_read_pending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len)
> +{
> + uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
> + uint32_t value = 0;
> + unsigned int i;
> +
> + /* Loop over all IRQs affected by this read */
> + for ( i = 0; i < len * 8; i++ )
> + {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
> +
> + if ( irq_is_pending(irq) )
> + value |= (1U << i);
Same question: shouldn't we take the irq->irq_lock?
> + vgic_put_irq(vcpu->domain, irq);
> + }
> +
> + return value;
> +}
> +
> +void vgic_mmio_write_spending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len,
> + unsigned long val)
> +{
> + uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
> + unsigned int i;
> + unsigned long flags;
> + irq_desc_t *desc;
> +
> + for_each_set_bit( i, &val, len * 8 )
> + {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
> +
> + spin_lock_irqsave(&irq->irq_lock, flags);
> + irq->pending_latch = true;
> +
> + /* To observe the locking order, just take the irq_desc pointer
> here. */
> + if ( irq->hw )
> + desc = irq_to_desc(irq->hwintid);
> + else
> + desc = NULL;
> +
> + vgic_queue_irq_unlock(vcpu->domain, irq, flags);
> +
> + /*
> + * When the VM sets the pending state for a HW interrupt on the
> virtual
> + * distributor we set the active state on the physical distributor,
> + * because the virtual interrupt can become active and then the guest
> + * can deactivate it.
> + */
> + if ( desc )
> + {
> + spin_lock_irqsave(&desc->lock, flags);
> + spin_lock(&irq->irq_lock);
> +
> + /* This h/w IRQ should still be assigned to the virtual IRQ. */
> + ASSERT(irq->hw && desc->irq == irq->hwintid);
> +
> + gic_set_active_state(desc, true);
> +
> + spin_unlock(&irq->irq_lock);
> + spin_unlock_irqrestore(&desc->lock, flags);
> + }
> +
> + vgic_put_irq(vcpu->domain, irq);
> + }
> +}
> +
> +void vgic_mmio_write_cpending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len,
> + unsigned long val)
> +{
> + uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
> + unsigned int i;
> + unsigned long flags;
> + irq_desc_t *desc;
> +
> + for_each_set_bit( i, &val, len * 8 )
> + {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
> +
> + spin_lock_irqsave(&irq->irq_lock, flags);
> + irq->pending_latch = false;
> +
> + /* To observe the locking order, just take the irq_desc pointer
> here. */
> + if ( irq->hw )
> + desc = irq_to_desc(irq->hwintid);
> + else
> + desc = NULL;
> +
> + spin_unlock_irqrestore(&irq->irq_lock, flags);
> +
> + /*
> + * We don't want the guest to effectively mask the physical
> + * interrupt by doing a write to SPENDR followed by a write to
> + * CPENDR for HW interrupts, so we clear the active state on
> + * the physical side if the virtual interrupt is not active.
> + * This may lead to taking an additional interrupt on the
> + * host, but that should not be a problem as the worst that
> + * can happen is an additional vgic injection. We also clear
> + * the pending state to maintain proper semantics for edge HW
> + * interrupts.
> + */
> + if ( desc )
> + {
> + spin_lock_irqsave(&desc->lock, flags);
> + spin_lock(&irq->irq_lock);
> +
> + /* This h/w IRQ should still be assigned to the virtual IRQ. */
> + ASSERT(irq->hw && desc->irq == irq->hwintid);
> +
> + gic_set_pending_state(desc, false);
Should we check irq_is_pending before calling gic_set_pending_state? I
am asking because I think it is possible to race against another
concurrent change that could come in after releasing irq_lock and before
taking desc->lock and irq->irq_lock again. If we check what's the latest
about the pending state we should be safe against the race, similarly to
what you did in the previous patch in vgic_sync_hardware_irq.
> + if (!irq->active)
> + gic_set_active_state(desc, false);
> +
> + spin_unlock(&irq->irq_lock);
> + spin_unlock_irqrestore(&desc->lock, flags);
> + }
> +
> +
> + vgic_put_irq(vcpu->domain, irq);
> + }
> +}
> +
> static int match_region(const void *key, const void *elt)
> {
> const unsigned int offset = (unsigned long)key;
> diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
> index a2cebd77f4..5c927f28b0 100644
> --- a/xen/arch/arm/vgic/vgic-mmio.h
> +++ b/xen/arch/arm/vgic/vgic-mmio.h
> @@ -97,6 +97,17 @@ void vgic_mmio_write_cenable(struct vcpu *vcpu,
> paddr_t addr, unsigned int len,
> unsigned long val);
>
> +unsigned long vgic_mmio_read_pending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len);
> +
> +void vgic_mmio_write_spending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len,
> + unsigned long val);
> +
> +void vgic_mmio_write_cpending(struct vcpu *vcpu,
> + paddr_t addr, unsigned int len,
> + unsigned long val);
> +
> unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
>
> #endif
> --
> 2.14.1
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |