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

[Brandon Perez <a0225893@xxxxxx>]

On 07/10/2015 05:30 AM, Ian Campbell wrote:
> Great, I'm glad you figured this out, it was really starting to stump
> me!
>
>
> 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.
    Yes, this makes sense. I'm working on modifying my device tree to 
get this working now.
> 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.
    I think, at least based on my current understanding of the Xen 
code, there's no real mechanism to do this as of yet. The guest is not 
capable of redefining an IRQ. At least in the short term, you could 
require that any interrupts which are passthrough be statically mapped 
(e.g. the mapping is set up by the bootloader, or the default is used). 
Then, Xen would need to be aware of the true IRQ number, and the kernel 
would have to take care to not remap this IRQ. The former can be 
accomlished with an additional property in the device tree, and the 
functionality for the latter already exists, at least for OMAP devices, 
where the interrupt is marked as "reserved".
   The other case to consider is when Xen requires an interrupt that is 
an SPI. The only case I've seen so far is the serial interrupt, which is 
controlled by Xen. For now, I'm adding a property to the UART device 
tree node that informs Xen of what the true IRQ number is. For now, the 
default mapping is used, and the Dom0 kernel makes sure not to override 
this mapping.
Brandon


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