Re: [Xen-devel] [GSOC-2019] Problem with initializing crossbar on bb-x15 in dom0

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Sat, 6 Jul 2019, Julien Grall wrote:
> On 06/07/2019 18:55, Denis Obrezkov wrote:
> > Hi,
> > 
> > On 7/6/19 7:37 PM, Julien Grall wrote:
> > 
> >>
> >> Yes it would be sensible to try to implement a crossbar driver in Xen
> >> and test with the UART. Looking at the driver in Linux, this should not
> >> be too difficult.
> > I don't understand why xen doesn't react on triple Ctrl+a. It probably
> > means that UART's interrupts doesn't work. But I was able to type in
> > u-boot so the uart should be already configured. Or not? Should I set up
> > it in a crossbar first?
> Xen is not able to deal with the crossbar. It means it cannot translate 
> the interrupt and therefore cannot initialize the UART:
> 
> (XEN) omap-uart: Unable to retrieve the IRQ
> (XEN) Unable to initialize dtuart: -22
> (XEN) Bad console= option 'dtuart'
> 
>  From my understanding, even if you are able to translate it, you don't 
> know how U-boot configured the crossbar. In other words, you don't know 
> which GIC Interrupt ID was used for the UART. So, you still need to 
> configure the crossbar in Xen.
> 
> >>
> >>>>
> >>
> >> I don't think I ever suggested to not expose the crossbar to Dom0.
> >> Instead, I suggested to virtualize for Dom0, so it can be used by Xen as
> >> well.
> >>
> >>>>
> >>>>> Also, the tegra
> >>>>> implementation blacklist only a uart.
> >>>>
> >>>> I don't understand this.
> >>> In here [1] you can find that only uart is blacklisted (in
> >>> tegra_blacklist_dev[]). So, in tegra they didn't blacklist their version
> >>> of the crossbar.
> >>
> >> This series has not been merged. In other word, the code is not yet
> >> matching the expectations of the maintainers.
> >>
> >> I pointed you to this series, because I think some of the idea could be
> >> re-used for implementing the crossbar.
> >>
> >> In this particular case, it has been suggested to use blacklist_dev
> >> rather than unmapping (see [2]).
> >>
> > 
> > Hm, I thought that idea behind the patch was that they unmap the control
> > register and intercept the calls from Linux to that control register. At
> > the same time they preserved the crossbar in the device tree. And, I
> > thought that you wanted to demonstrate this exact thing.
> 
> I think unmapping something you just mapped is a gross hack. It would be 
> best if this can be avoided.
> 
> Also, I am also not entirely convince we want to fully preserve the 
> crossbar node in the DT. It will depend how the crossbar will be 
> virtualized for Dom0.
> 
>  From my understanding, the crossbar is able to handle N irqs. For each 
> irqs, there will be a corresponding register.
> 
> The simplest approach would be to expose exactly the same crossbar to 
> Dom0 and trap all the access. Any access to registers associated to IRQs 
> used by Xen would just be ignored. In this approach, we would probably 
> want to update ti-irqs-skip/ti,irqs-reserved.

This is similar to what I suggested to Denis on IRC. Denis, is you still
have the logs, you should find some more pointers in the same direction.


> > Could you
> > describe how in general the approach with blacklisting should work?
> 
> I didn't fully thought through so far.
> 
> On a second thought, this may not work correctly. We want to keep the 
> crossbar node path the same to avoid issue with aliasing (see /aliases).
> 
> So probably the best would be to match the crossbar compatible and then 
> alter anything we want. See how we deal with the GIC in make_gic_node.
> 
> In summary:
>     1) A platform callback (maybe platform_specific_mapping) will hook 
> the handlers for the crossbar
>     2) handle_node is extended to catch the crossbar node. For now, , 
> you could hack domain_build.c to match the callback. This allows you to 
> focus on virtualizing the crossbar. We can discuss a better approach 
> later on.

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