[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 05/17] xen/arm: ITS: implement hw_irq_controller for LPIs
On Tue, Jul 14, 2015 at 2:48 AM, Julien Grall <julien.grall@xxxxxxxxxx> wrote: > Hi, > > On 10/07/2015 09:42, vijay.kilari@xxxxxxxxx wrote: >> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c >> index c41e82e..4f3801b 100644 >> --- a/xen/arch/arm/gic.c >> +++ b/xen/arch/arm/gic.c >> +static inline hw_irq_controller *get_host_hw_irq_controller(unsigned int >> irq) >> +{ >> + if ( is_lpi(irq) ) >> + return its_hw_ops->lpi_host_irq_type; >> + else >> + return gic_hw_ops->gic_host_irq_type; >> +} > > > This is not what I asked on v3 [1]. The ITS hardware controller shouldn't be > exposed to the common GIC. We have to keep a clean and comprehensible > interface. > > What I asked is to replace the gic_host_irq_type variable by a new callback > which will return the correct hw_irq_controller. > > For GICv2, it will return the same hw_irq_controller as today. For GICv3, it > will check is the IRQ is an LPI and return the correct controller. > > FWIW, it was "ack" by Ian [2]. If we don't want to expose any ITS interfaces to common gic code, then we have to register callbacks to GICv3 driver. > >> + >> +static inline hw_irq_controller *get_guest_hw_irq_controller(unsigned int >> irq) >> +{ >> + if ( is_lpi(irq) ) >> + return its_hw_ops->lpi_guest_irq_type; >> + else >> + return gic_hw_ops->gic_guest_irq_type; >> +} >> + >> /* >> * needs to be called with a valid cpu_mask, ie each cpu in the mask has >> * already called gic_cpu_init >> @@ -104,7 +126,8 @@ static void gic_set_irq_properties(struct irq_desc >> *desc, >> const cpumask_t *cpu_mask, >> unsigned int priority) >> { >> - gic_hw_ops->set_irq_properties(desc, cpu_mask, priority); >> + if ( desc->irq < gic_number_lines() ) >> + gic_hw_ops->set_irq_properties(desc, cpu_mask, priority); >> } > > > Why this function can't be called for LPI? The configuration should likely > be the same... > >> @@ -149,7 +173,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned >> int virq, >> test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) ) >> goto out; >> >> - desc->handler = gic_hw_ops->gic_guest_irq_type; >> + desc->handler = get_guest_hw_irq_controller(desc->irq); >> set_bit(_IRQ_GUEST, &desc->status); >> >> gic_set_irq_properties(desc, cpumask_of(v_target->processor), >> priority); >> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c >> index 2dd43ee..ba8528a 100644 >> --- a/xen/arch/arm/irq.c >> +++ b/xen/arch/arm/irq.c >> @@ -35,7 +35,13 @@ static DEFINE_SPINLOCK(local_irqs_type_lock); >> struct irq_guest >> { >> struct domain *d; >> - unsigned int virq; >> + union >> + { >> + /* virq refer to virtual irq in case of spi */ >> + unsigned int virq; >> + /* virq refer to event ID in case of lpi */ >> + unsigned int vid; > > > Why can't we store the event ID in the irq_guest? As said on v3, this is not Are you referring to irq_desc in above statement? > domain specific [3]. Furthermore, you add support to route LPI in Xen (see > gic_route_irq_to_xen) where you will clearly need the event ID. > >> void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask) >> { >> if ( desc != NULL ) >> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h >> index b5e09bd..e8d244f 100644 >> --- a/xen/include/asm-arm/gic-its.h >> +++ b/xen/include/asm-arm/gic-its.h >> @@ -161,6 +161,10 @@ typedef union { >> * The ITS view of a device. >> */ >> struct its_device { >> + /* Physical ITS */ >> + struct its_node *its; >> + /* Number of Physical LPIs assigned */ >> + int nr_lpis; > > > Why didn't you add this field directly in the patch #4? It would be more > logical. > >> /* >> * ITS registers, offsets from ITS_base >> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h >> index 34b492b..55e219f 100644 >> --- a/xen/include/asm-arm/irq.h >> +++ b/xen/include/asm-arm/irq.h >> @@ -17,6 +17,8 @@ struct arch_pirq >> struct arch_irq_desc { >> int eoi_cpu; >> unsigned int type; >> + struct its_device *dev; >> + u16 col_id; > > > It has been suggested by Ian to move col_id in the its_device in the > previous version [4]. Any reason to not doing it? In round robin fashion each plpi is attached to col_id. So storing in its_device is not possible. In linux latest col_id is stored in its_device structure for which set_affinity is called. > > Regards, > > [1] http://www.gossamer-threads.com/lists/xen/devel/386493#386493 > [2] http://www.gossamer-threads.com/lists/xen/devel/386771#386771 > [3] http://www.gossamer-threads.com/lists/xen/devel/385521#385521 > [4] http://www.gossamer-threads.com/lists/xen/devel/387586#387586 > > -- > Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |