Re: [Xen-devel] [PATCH] xen/arm: Don't hardcode event channel IRQ

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-05-20 at 16:58 +0100, Julien Grall wrote:
> On 05/20/2013 04:32 PM, Ian Campbell wrote:
> 
> > On Fri, 2013-05-17 at 11:49 +0100, Julien Grall wrote:
> >> @@ -467,9 +477,41 @@ static int handle_node(struct domain *d, const struct 
> >> dt_device_node *np)
> >>  
> >>  static int map_devices_from_device_tree(struct domain *d)
> >>  {
> >> +    bool_t ppis[NR_PPI_IRQS] = {0};
> >> +    int res;
> >> +    unsigned int i;
> >> +
> >>      ASSERT(dt_host && (dt_host->sibling == NULL));
> >>  
> >> -    return handle_node(d, dt_host);
> >> +    res = handle_node(d, dt_host, ppis);
> >> +
> >> +    /*
> >> +     * Fill by hand timer IRQS ppis as we don't map it in Dom0
> >> +     * We assume the host IRQs and the dom0 IRQs are the same for the 
> >> timer.
> > 
> > This seems a bit fragile, what happens if new interrupts are added in
> > the future?
> 
> 
> Right, but it's only for the timer as timer is "shared" between Xen and
> dom0 (ie: we fake the timer IRQs).

Right now it is...

> > Can the gic.c code not track the PPIs which are either assigned to Xen
> > or a guest? 
> > Or perhaps better vgic.c should know if which if any IRQs are routed for
> > a given guest. We may need to add a function to allow the vtimer code to
> > reserve the virtual interrupts which it is going to use. Seems odd that
> > we don't have an existing equivalent to gic_route_irq_to_guest in
> > vtimer.c...
> 
> 
> vtimer will manually inject the virtual IRQ as IRQs are forwarded to the
> running vCPU. gic_route_irq_to_guest will always route to a specific domain.

Right. My point was that there should be an equivalent to
gic_route_irq_to_guest which basically says "this IRQ is valid for this
domain (or vcpu) and I will be manually injecting this IRQ" without
routing a real IRQ to it i.e. some new vgic function which is called
from vcpu_vtimer_init().

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel