Re: [Xen-devel] [GSoC-2019] About the crossbar and xen

[Hunyue Yau <hy-gsoc@hy-research.com>]

[This mail incorporates comments raised on IRC. I have made some of this more 
verbose to provide context to people that haven't seen the IRC comments.]

This will be a bunch of facts on the am5. Someone else will have relate it 
back to Xen.

1 - The WUGen is a hardware block on the MPU block that can turn interrupts 
into wake up events if the MPU is in certain deeper sleep states. This applies 
only to certain interrupts. We can confirm this by looking at the DT's register 
address. Per the TRM, they are registers for the MPU's PRCM (Power/Reset/Clock 
Management). In short, this block makes interrupts a possible wake up source. 

2 - Earlier kernels did not expose that HW block. See this patch that 
introduced the WUGen - 
https://github.com/torvalds/linux/commit/7136d457f365ecc93ddffcdd42ab49a8473f260b
I suspect looking at the before part of the patch should provide clues on how 
to handle the WUGen.


3 - This may be redundant but more definitions (in the human sense) here: 
https://www.mjmwired.net/kernel/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu

4 - For the UART case, I suspect the flow Dennis pointed out is about right. 
However, that may be different depending on the interrupt source.

Unknowns from my point of view - 

a - Does Xen virtualize power management? If so, this may have have an impact. 
I would not recommend adding PM virtualization in GSoC. It is tugging on a 
very long string. 

b - If Xen does not virtualize that, someone needs to decide how much to leave 
to the guess. 

c - I wonder if we can do a half way hack where the kernel sets up the PM but 
Xen hooks to get the interrupt. The HW will do its PM thing and Xen can 
process the interrupt.

Guesses/possible hacks -
- For the interrupts we care about, the cross bar can route things to the MPU 
unconditionally. This would break the other HW blocks but most of them aren't 
needed for boot.

On Thursday, July 11, 2019 18:32:22 Julien Grall wrote:
> On 7/11/19 1:50 PM, Denis Obrezkov wrote:
> > Hi,
> 
> Hi,
> 
> >>> I am interested whether we should do something with omap5-wugen-mpu. I
> >>> found that crossbar is connected to GIC. And on some schemes in trm it
> >>> is connected via omap5-wugen-mpu. So, it is not clear for me whether it
> >>> should be handled in xen.
> 
> I don't know much about omap5-wugen-mpu, so I will leave Hunyue and Iain
> to provide feedback here.
> 
> > Also, I am interested in how to add the crossbar. I can see two options
> > as we discussed earlier. The first option is to remove the crossbar but
> > for me it might cause some problems since a guest might want to use it.
> > The second option is to expose the crossbar and intercept all the calls
> > to it. But the problem is that now xen supports only one
> > interrupt-controller. And at the same time most of the SPI IRQs are
> > mapped to the crossbar. So, when xen checks whether the main
> > interrupt-controller is the same as the one to who external interrupts
> > are mapped it fails.
> > (xen/common/device_tree.c:dt_irq_translate()).
> > And I don't think that I should change interrupt-parent option of
> > devices to map them to the GIC because it is essentially the first
> > option mentioned above. So, it seems that probably interrupt-parent
> > finding decision logic should be changed a bit? Like to find a GIC node
> > not in a direct interrupt-parent but transitively in one of ancestors:
> > 
> > UART -> crossbar -> wugen -> GIC
> > 
> > What do you think?
> 
> Have you looked at the series I pointed out earlier on? It extends Xen
> to support other interrupt controller parent.
> 
> Cheers,

-- 
Hunyue Yau
http://www.hy-research.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel