Re: [Xen-devel] [RFC] Add support for Xen ARM guest on FreeBSD

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-01-17 at 00:36 +0000, Julien Grall wrote:
> 
> On 01/16/2014 01:56 AM, Nathan Whitehorn wrote:
> >
> > Thanks for the CC. Could you explain what you mean by "grant-parent"
> > etc? "interrupt-parent" is a fundamental part of the way PAPR (and
> > ePAPR) work, so I'm very very hesitant to start guessing. I think things
> > have broken for you because some (a lot, actually) of OF code does not
> > expect #interrupt-cells to be more than 2. Some APIs might need
> > updating, which I'll try to take care of. Could you tell me what the
> > difference between SPI and PPI is, by the way?
> 
> Sorry, I also made some typoes in my explanation so it was not clear.
> 
> interrupt-parent is a property in a device node which links this node to 
> an interrupt controller (in our case the GIC controller).
> 
> The way to handle it on Linux and the ePAR is different:
>     - ePAR (chapter 2.4) says:
> The physical wiring of an interrupt source to an interrupt controller is 
> represented in the device tree with the interrupt-parent property. Nodes 
> that represent interrupt-generating devices contain an
> interrupt-parent property which has a phandle value that points to the 
> device to which the device's interrupts are routed, typically an 
> interrupt controller. If an interrupt-generating device does not have
> an interrupt-parent property, its interrupt parent is assumed to be its 
> device tree parent.
>  From my understanding, it's mandatory to have an interrupt-parent 
> property on each device node which is using interrupts. If it doesn't 
> exist it will assume that the parent is interrupt controller.
> If I'm mistaken, at least FreeBSD handle the interrupt-parent property 
> in this way.
>     - Linux implementation will look at to the node, if the property 
> doesn't exists, it will check if the ancestor has this property ...
> 
> So the device tree below is valid on Linux, but not on FreeBSD:
> 
> / {
>    interrupt-parent = &gic
> 
>    gic: gic@10
>    {
>      ...
>    }
> 
>    timer@1
>    {
>      interrupts = <...>
>    }
> }
> 
> Most of shipped device tree use this trick.
> 
> IanC: I was reading the linux binding documentation 
> (devicetree/booting-without-of.txt VII.2) and it seems that the 
> explanation differs from the implementation, right?

I vaguely recall someone saying that the Linux behaviour was a quirk of
some real PPC system which supplied a DTB which required this behaviour
which has leaked into the other platforms. It does also sound like a
useful extension to the spec which makes the dtb easier to write.

The right place to discuss this would probably be either #devicetree on
freenode or devicetree@xxxxxxxxxxxxxxxx

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

Is the root node not considered to be a "top-level simple-bus" with a
1:1 mapping of MMIO and interrupts? (Linux seems to treat it this way,
but I haven't trawled the docs for a spec reference to back that
behaviour up). I take it BSD doesn't do this?

Ian.


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