[RFC] Add support for Xen ARM guest on FreeBSD

[Nathan Whitehorn]

On 01/17/14 07:45, Julien Grall wrote:
>
>
> On 01/17/2014 03:04 AM, Nathan Whitehorn wrote:
>> On 01/16/14 18:36, Julien Grall wrote:
>>
>> The specification is actually a little unclear on this point, but
>> FreeBSD follows the same rules as Linux in any case. Most, if not all,
>> FreeBSD code should check any ancestor at this point as well. In
>> particular fdt_intr_to_rl does this. What it *doesn't* do is allow
>> #interrupt-cells to be larger than 2. I'll fix this this weekend.
>
> Thanks, for working on this part.
>
> Another things to take into account: the first cell doesn't always 
> contain the interrupt.
> With the Linux binding (#interrupt-cells == 3)
>   - cell 1: 1 or 0 (PPI vs SPI)
>   - cell 2: relative IRQ number to the start of PPI/SPI
>   - cell 3: cpu mask + interrupt flags (edge/level...)
> `

Yep. This will require a little API redesign, but shouldn't be that bad.

>>>> On the subject of simple-bus, they usually aren't necessary. For
>>>> example, all hypervisor devices on IBM hardware live under /vdevice,
>>>> which is attached to the device tree root. They don't use MMIO, so
>>>> simple-bus doesn't really make sense. How does Xen communicate with 
>>>> the
>>>> OS in these devices?
>>>> -Nathan
>>>
>>> As I understand, only the simple bus code (see simplebus_attach) is
>>> translating the interrupts in the device on a resource.
>>> So if you have a node directly attached to the root node with
>>> interrupts and MMIO, the driver won't be able to retrieve and
>>> translate the interrupts via bus_alloc_resources.
>>
>> Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this.
>
> I have noticed at least one issue (which is not related to my problem):
>   - When the OFW nexus translate IRQ (with #interrupt-cells > 1), the 
> rid will be equal to 0, 0 + #interrupt-cells, ... So the number will 
> be discontinued. Rather than on simple-bus for the same device, the 
> rid will be 0, 1, 2...

Interesting. I'll investigate.

> For my issue, I will look at it again this week-end.
>
> BTW when I look to the FDT (sys/dev/fdt_common.c) and the ofw 
> (sys/dev/ofw_nexus.c) code, I have notice that lots of code are 
> duplicated.
>
> It would be nice to have common helper to avoid duplicate code and 
> issue for the future :).
>

I'm in the middle of cleaning all this up (which is how I'm on the hook 
for breaking your case!). Most of fdt_common.c is not long for this world.
-Nathan