|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 33/49] ARM: new VGIC: Add PRIORITY registers handlers
Hi,
On 16/02/18 17:38, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> The priority 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.
>> There is a corner case when we change the priority of a pending
>> interrupt which we don't handle at the moment.
>>
>> This is based on Linux commit dd238ec2b87b, written by Andre Przywara.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
>> ---
>> xen/arch/arm/vgic/vgic-mmio-v2.c | 4 ++--
>> xen/arch/arm/vgic/vgic-mmio.c | 47
>> ++++++++++++++++++++++++++++++++++++++++
>> xen/arch/arm/vgic/vgic-mmio.h | 7 ++++++
>> xen/arch/arm/vgic/vgic.h | 2 ++
>> 4 files changed, 58 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c
>> b/xen/arch/arm/vgic/vgic-mmio-v2.c
>> index eba24d9866..0574ff9b16 100644
>> --- a/xen/arch/arm/vgic/vgic-mmio-v2.c
>> +++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
>> @@ -92,8 +92,8 @@ static const struct vgic_register_region
>> vgic_v2_dist_registers[] = {
>> vgic_mmio_read_active, vgic_mmio_write_cactive, NULL, NULL, 1,
>> VGIC_ACCESS_32bit),
>> REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
>> - vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 8,
>> - VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
>> + vgic_mmio_read_priority, vgic_mmio_write_priority, NULL, NULL,
>> + 8, VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
>> REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
>> vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 8,
>> VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
>> diff --git a/xen/arch/arm/vgic/vgic-mmio.c
>> b/xen/arch/arm/vgic/vgic-mmio.c
>> index ac3aa03fbc..14570d9d8e 100644
>> --- a/xen/arch/arm/vgic/vgic-mmio.c
>> +++ b/xen/arch/arm/vgic/vgic-mmio.c
>> @@ -309,6 +309,53 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
>> spin_unlock(&vcpu->domain->domain_lock);
>> }
>> +unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
>> + paddr_t addr, unsigned int len)
>
> Indentation.
>
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 8);
>
> uin32_t
>
>> + int i;
>
> unsigned int
>
>> + u64 val = 0;
>
> uint64_t
>
>> +
>> + for ( i = 0; i < len; i++ )
>> + {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
>> + i);
>> +
>> + val |= (u64)irq->priority << (i * 8);
>
> uint64_t
>
>> +
>> + vgic_put_irq(vcpu->domain, irq);
>> + }
>> +
>> + return val;
>> +}
>> +
>> +/*
>> + * We currently don't handle changing the priority of an interrupt that
>> + * is already pending on a VCPU. If there is a need for this, we would
>> + * need to make this VCPU exit and re-evaluate the priorities,
>> potentially
>> + * leading to this interrupt getting presented now to the guest (if
>> it has
>> + * been masked by the priority mask before).
>> + */
>> +void vgic_mmio_write_priority(struct vcpu *vcpu,
>> + paddr_t addr, unsigned int len,
>> + unsigned long val)
>
> Indentation
>
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 8);
>
> uint32_t
>
>> + int i;
>
> unsigned int
>
>> + unsigned long flags;
>> +
>> + for ( i = 0; i < len; i++ )
>> + {
>
> I believe this code will be follow the atomicity when 2 vCPUs (A and B)
> write to this register. The result should be either the value of write A
> or write B. But not a mix of the both.
To somewhat summarise our IRL discussion:
Yes, technically I believe this is correct: We should first lock all
affected IRQs, then update the priorities, then unlock (in opposite
order). But: I don't think this is really critical: Two concurrent
writes to the same register are not reliable in the first place, every
sane driver (in the guest in our case) would always take a lock to
prevent this. So while technically the 32-bit MMIO write needs to be
atomic from an ARM ARM point of view, this does not extend to the actual
GIC effects, I believe.
And there are no bad effects to the HV from those being mixed up, so I
tend to ignore this for now.
I have a patch fixing this, but don't believe it's worth the effort and
has other recuperations like introducing a locking order on IRQs as well.
Fixed the rest.
Cheers,
Andre.
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
>> + i);
>> +
>> + spin_lock_irqsave(&irq->irq_lock, flags);
>> + /* Narrow the priority range to what we actually support */
>> + irq->priority = (val >> (i * 8)) & GENMASK(7, 8 -
>> VGIC_PRI_BITS);
>> + spin_unlock_irqrestore(&irq->irq_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 39e854232e..30221096b9 100644
>> --- a/xen/arch/arm/vgic/vgic-mmio.h
>> +++ b/xen/arch/arm/vgic/vgic-mmio.h
>> @@ -170,6 +170,13 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
>> paddr_t addr, unsigned int len,
>> unsigned long val);
>> +unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
>> + paddr_t addr, unsigned int len);
>> +
>> +void vgic_mmio_write_priority(struct vcpu *vcpu,
>> + paddr_t addr, unsigned int len,
>> + unsigned long val);
>> +
>> unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
>> /* Find the proper register handler entry given a certain address
>> offset */
>> diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
>> index 82fe902e26..b104f8e964 100644
>> --- a/xen/arch/arm/vgic/vgic.h
>> +++ b/xen/arch/arm/vgic/vgic.h
>> @@ -20,6 +20,8 @@
>> #define PRODUCT_ID_KVM 0x4b /* ASCII code K */
>> #define IMPLEMENTER_ARM 0x43b
>> +#define VGIC_PRI_BITS 5
>> +
>> #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
>> static inline bool irq_is_pending(struct vgic_irq *irq)
>>
>
> Cheers,
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |