Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-07-09 at 11:17 -0400, Brandon Perez wrote:
>      Thanks, for the clarifications on my questions on interrupt/timer 
> code flow in Xen. That made it a lot clearer. I figured out what is 
> causing the bug, and it turned out to be one of the local changes I had 
> to Xen.

Great, I'm glad you figured this out, it was really starting to stump
me!

>      On the DRA72x device, there are a large number of peripheral 
> devices, more than can be handled by the SPI on the GIC. Therefore, 
> there's an internal mechanism that allows the routing of these 
> peripherals to the interrupt lines on the GIC.

Right, this (secondary/chained interrupt controllers) is a quite common
occurrence on ARM systems I think, but not one we've had to deal with
until now.

Assuming the devices behind this chained controller are not targets for
passthrough then I think the solution is reasonably easy (at least
architecturally), it just needs a small bit of infrastructure code and a
small bit of per-controller code in Xen, matched on the DT
compatibility-string of the nested controller (possibly the
per-controller code might even be as small as _just_ the compat string
in a list).

Upon discovering such an chained interrupt-controller node in the DT all
of the output SPIs should be routed to dom0 and all the associated MMIO
ranges should be mapped to dom0 etc etc (perhaps the new
dt_for_each_range and/or dt_for_each_irq_map functions would help here).

Upon discovering a device whose interrupt-parent is one of these chained
interrupt controllers (or anything not the root GIC really) then it's
own interrupt property can just be passed through unchanged without
mapping anything.

Now dom0 can prod this new controller to its hearts content and the
resulting SPIs will be correctly routed to dom0.

If they are targets for passthrough then something more complex would be
needed, involving quite a bit more code on the Xen side, I expect. I've
not considered this case very deeply.

Ian.


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