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

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

On 07/14/2015 04:43 AM, Ian Campbell wrote:
On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote:
On 07/13/2015 04:29 AM, Ian Campbell wrote:
On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote:

Is there a 1:1 mapping between (active) interrupts handled by this
cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16
SPIs would you only be able to use 16 of the devices?

Or does it support multiple interrupt sources triggering a single SPI?

      For the chip I'm working with, it only supports a 1:1 mapping. It
doesn't allow for multiple interrupts to share an SPI line.

This simplifies things somewhat for passthrough then, I think. You
simply leave routing and assignment of interrupts to SPIs in the hands
of dom0, and on passthrough it would pass the SPI to the guest with
appropriate values for the interrupt-parent and interrupts properties.

Right, this is a tricky one. Other than various solutions involving
trusting the firmware to get it right and requiring dom0 to not muck
around with it the only other solution I can think of would be a bit of
code in Xen which traps dom0's attempted changes and validates them,
preventing dom0 from mucking with the ones Xen cares about.

Given how simple these sorts of interrupt remappers often are that might
not even be that much code.


      I think that wouldn't be too difficult to do, but for now, I'm
going to stick with using the device tree to inform Xen and the Kernel.


Hi Ian,

This question pertains to what we've been talking about, so I'm going to keep it on this thread.

I was hoping to get some clarification on how secondary interrupts are passed to Dom0 by Xen. My current understanding is as follows. When Xen constructs Dom0, it goes through each entry in the device tree. It then reads out each entry in the "interrupts" property. If the device is connected to the primary interrupt controller, then Xen performs the necessary steps to allocate the IRQ to the guest, and then route it to the guest also. Otherwise, if the controller is not the primary one, then Xen does nothing. This all happens in handle_device().

Here's where my understanding becomes a little less clear. Later on, the kernel will boot, and as needed, will write to its vGIC. This will be trapped into Xen as a data abort, and handled as an MMIO write. Eventually, it makes its way to the function gicv2_irq_enable(), which actually writes to the vGIC and GIC to enable said interrupt. Does this sound right, or am I missing some key components?

I'm attempting to enable the kernel to handle the mapping and routing of IRQ's on the crossbar. So, what I'm doing is, for each device in the DT that is a peripheral device (SPI), I'm changing its "interrupt-parent" property to be a device node representing the crossbar.

However, this is leading to data aborts and/or interrupts not being delivered to the kernel. Either the kernel encounters a data abort (presumably due to the fact that it does not have permission for the IRQ), or I find the kernel running in "idle_loop()" (which in my experience means its waiting for an interrupt to be delivered).

Is the functionality in Xen to allow me to passthrough secondary interrupts like this, or will some changes be needed? If so, could you point me in the right direction?


Xen-users mailing list



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