From owner-freebsd-xen@FreeBSD.ORG Fri Jan 17 09:29:28 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AB021D5; Fri, 17 Jan 2014 09:29:28 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 30A361FCD; Fri, 17 Jan 2014 09:29:26 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="93794219" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 17 Jan 2014 09:29:24 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL03.citrite.net (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Fri, 17 Jan 2014 04:29:24 -0500 Message-ID: <1389950962.6697.33.camel@kazak.uk.xensource.com> Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD From: Ian Campbell To: Julien Grall Date: Fri, 17 Jan 2014 09:29:22 +0000 In-Reply-To: <52D87B15.5090208@linaro.org> References: <1389733267-20822-1-git-send-email-julien.grall@linaro.org> <24851B79-7EC7-4E3A-94DB-4B9B86FDFFFC@bsdimp.com> <52D6B62A.9000208@linaro.org> <52D73C4E.2080306@freebsd.org> <52D87B15.5090208@linaro.org> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, Nathan Whitehorn , gibbs@freebsd.org, Warner Losh X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 09:29:28 -0000 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@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.