On Fri, 2015-06-26 at 17:05 +0200, Julien Grall wrote: > Hi Vijay, > > On 26/06/2015 14:54, Vijay Kilari wrote: > > On Tue, Jun 23, 2015 at 8:02 PM, Julien Grall <julien.gr...@citrix.com> > > wrote: > >> Hi Vijay, > >> > >> On 22/06/15 13:01, vijay.kil...@gmail.com wrote: > >>> From: Vijaya Kumar K <vijaya.ku...@caviumnetworks.com> > >>> > >>> Implements hw_irq_controller api's required > >>> to handle LPI's > >> > >> This patch doesn't hw_irq_controller for LPI but just hack around the > >> current GICv3 host hw_irq_controller. > >> > >> As said on the previous version, the goal of hw_irq_controller is too > >> keep things simple (i.e few conditional code). Please introduce a > >> separate hw_irq_controller for LPIs. > > > > If new hw_irq_controller is introduced for LPIs, then this has to > > be exported using some lpi structure which holds pointer to > > hw_irq_controller > > for guest & host type similar to gic_hw_ops > > The interface is not set in stone, you are free to change what you want > as long as we keep something clean and comprehensible. It's the same for > the functions (I have in mind route_irq_to_guest).
Ack. > In this case, I would prefer to see 2 callbacks (one for the host the > other for the guest) which return the correct IRQ controller for a > specific IRQ. I have in mind something like: > > get_guest_hw_irq_controller(unsigned int irq) > { > if ( !is_lpi ) > return &gicv3_guest_irq_controller > else > return &gicv3_guest_lpi_controller > } > > Same for the host irq controller. So the selection of the IRQ controller > would be hidden from gic.c and keep the code a generic as possible. Yes, this is how I would expect it too. Alternatively I notice that the pattern today is: desc->handler = gic_hw_ops->gic_(host|guest)_irq_type; [set_bit(_IRQ_GUEST, &desc->status) or not] gic_set_irq_properties(desc,[...]); So an alternative might be for the set_irq_properties hook in the ops to also setup the handler (based on desc->status&_IRQ_GUEST and desc->irq), perhaps renaming it to something less "property" based. Both callers are git_route_irq_to_... so perhaps gic_route_irq? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel