[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 23/27] ARM: vITS: handle INV command
On 04/04/17 17:51, Julien Grall wrote: > Hi Andre, > > On 03/04/17 21:28, Andre Przywara wrote: >> The INV command instructs the ITS to update the configuration data for >> a given LPI by re-reading its entry from the property table. >> We don't need to care so much about the priority value, but enabling >> or disabling an LPI has some effect: We remove or push virtual LPIs >> to their VCPUs, also check the virtual pending bit if an LPI gets >> enabled. >> >> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> >> --- >> xen/arch/arm/vgic-v3-its.c | 62 >> ++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 62 insertions(+) >> >> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c >> index 2f024b1..920c437 100644 >> --- a/xen/arch/arm/vgic-v3-its.c >> +++ b/xen/arch/arm/vgic-v3-its.c [ ... ] >> + >> + if ( *property & LPI_PROP_ENABLED ) >> + { >> + unsigned long flags; >> + >> + set_bit(GIC_IRQ_GUEST_ENABLED, &p->status); >> + spin_lock_irqsave(&vcpu->arch.vgic.lock, flags); >> + if ( !list_empty(&p->inflight) && >> + !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) ) >> + gic_raise_guest_irq(vcpu, vlpi, p->lpi_priority); >> + spin_unlock_irqrestore(&vcpu->arch.vgic.lock, flags); >> + >> + /* Check whether the LPI has fired while the guest had it >> disabled. */ >> + if ( test_and_clear_bit(GIC_IRQ_GUEST_LPI_PENDING, &p->status) ) >> + vgic_vcpu_inject_irq(vcpu, vlpi); >> + } >> + else >> + { >> + clear_bit(GIC_IRQ_GUEST_ENABLED, &p->status); >> + gic_remove_from_queues(vcpu, vlpi); >> + } > > This could looks quite similar to vgic_{enable,disable}_irqs. This is a > call to refactor the code there. I tried it and it doesn't work easily, because the part that handles a single (non-virtual) interrupt calls vgic_get_virq_type(), whose parameters break the abstraction of a single interrupt. Given that I am bit wary of bending a core GIC function just for the sake of refactoring just a second user. Cheers, Andre. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |