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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote:
> > 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".

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?

>     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.

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.


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