[RFC] Add support for Xen ARM guest on FreeBSD
Ian Campbell
Ian.Campbell at citrix.com
Fri Jan 17 09:29:28 UTC 2014
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 at 10
> {
> ...
> }
>
> timer at 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 at vger.kernel.org.
> > 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.
More information about the freebsd-xen
mailing list