Re: [Xen-devel] [RFC PATCH v3 07/18] xen/arm: ITS: implement hw_irq_controller for LPIs

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.grall@xxxxxxxxxx> 
> > wrote:
> >> Hi Vijay,
> >>
> >> On 22/06/15 13:01, vijay.kilari@xxxxxxxxx wrote:
> >>> From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>
> >>>
> >>> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel