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

[Brandon Perez <a0225893@xxxxxx>]

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.
> > >
> > > Ian.
> >       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.
> Sure.
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?
Brandon

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