Re: [Xen-devel] [XenARM] XEN tools for ARM with Virtualization Extensions

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2013-07-10 at 23:04 +0100, Julien Grall wrote:
> On 10 July 2013 20:38, Eric Trudeau <etrudeau@xxxxxxxxxxxx> wrote:
> >> > What functions should I call to implement  XEN_DOMCTL_bind_pt_irq on
> >> ARM?
> >>
> >> There's a function like route_irq_to_guest which we use to route IRQs to
> >> dom0 during boot. In principal that could also be used to reroute an IRQ
> >> to a guest, but I'm not sure how it will interact with the reassignment,
> >> since in your case the IRQ starts off bound to dom0. Hopefully it's just
> >> a small change to make it work for this case.
> >>
> >
> > In gic_route_irq_to_guest(), there is this call:
> >     gic_set_irq_properties(irq->irq, level, 1u << smp_processor_id(), 0xa0);
> >
> > I believe this will mean all IRQs will be routed on the current processor.
> > I believe this is PCPU0 when the dom0 device tree is being parsed.
> > When the PHYSDEVOP_map_pirq call is handled by the Hypervisor, the PCPU
> > may be any of the processors.
> > Is there a reason when we only route the IRQs for Dom0 to one PCPU?
> > If only one is allowed, should it be PCPU0?
> 
> I don't see any particular reason to route the PIRQs on only PCPU0.
> I think it's because Xen only routes SPIs to VCPU0, which is mostly
> running on PCPU0.
> 
> The best solution is routing the PIRQ on the PCPU which is running the VCPU.

For interrupts which are routed to the guest we should track the guest's
writes to the virtual target registers and then configure the physical
target registers correctly when migrating vcpus around so that the
interrupt follows the vcpu around.

Ian.

> 
> --
> Julien Grall



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