[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 07/10/2015 05:30 AM, Ian Campbell wrote:

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

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.


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.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.