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

[Julien Grall <Julien.Grall@xxxxxxx>]

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.

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

Cheers,

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