[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



Hi,

On 27/03/18 22:14, Stefano Stabellini wrote:
> 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.

Yeah, that's a good point, that belongs to the condition of "nothing
(critical) has changed meanwhile".

Cheers,
Andre.

>> +            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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.