From owner-freebsd-arm@FreeBSD.ORG Fri Jan 17 00:36:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E36D26C for ; Fri, 17 Jan 2014 00:36:48 +0000 (UTC) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1770192E for ; Fri, 17 Jan 2014 00:36:47 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id l18so1228815wgh.5 for ; Thu, 16 Jan 2014 16:36:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4wXhBVEK9bu6kQV4qJr65d7sAYxtH2FVJr6eGR3jehM=; b=Pfd+6u5bKCsezYIG0UcNIuLeXH/VIFAyKUM6F0zcV6vSbpK9bK9omUC4/ABLaQb/CY 2lLKkXeQQWw+OIlJazFHMVJQGLYwRR4v7wyO8c9Au7xnGe34YLCdG6BP3fRMdF1/27eh UPfrE10FcfZ5LBxCXmexIhjqmCw7n3NpL2p4hbfpCT0Gaoee7apfD66hsj5AY0BdERpY J174x9x91TDqMvdxtEheH/0VBknJeMFXPGZEJwBHT5Rv3CJHGwQcKVqYLZtLp3jLYRlB 3Z/buOVuxmGmXZeYZPL3pbcHt8Bmjn+8CfHDKFLWCmBQosW9QuHk2IpkbHAW+ZoMqq3v u3zA== X-Gm-Message-State: ALoCoQl0XBIm+P/DagTsmuJQbANWOslcKh8U2XQbW1RUSkhf3QSYgRmhLkqEEEudcKm1w2YYXGXJ X-Received: by 10.180.80.103 with SMTP id q7mr30118wix.14.1389919000069; Thu, 16 Jan 2014 16:36:40 -0800 (PST) Received: from [192.168.0.2] (cpc8-cmbg15-2-0-cust169.5-4.cable.virginm.net. [86.30.140.170]) by mx.google.com with ESMTPSA id ea4sm402202wib.7.2014.01.16.16.36.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 16:36:39 -0800 (PST) Message-ID: <52D87B15.5090208@linaro.org> Date: Fri, 17 Jan 2014 00:36:37 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Whitehorn , Warner Losh Subject: Re: [RFC] Add support for Xen ARM guest on FreeBSD 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> In-Reply-To: <52D73C4E.2080306@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, freebsd-xen@freebsd.org, freebsd-arm@FreeBSD.org, gibbs@freebsd.org, roger.pau@citrix.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 00:36:48 -0000 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? For the #interrupt-cells property, the problem starts in fdt_intr_to_rl (sys/dev/fdt/fdt_common.c:476). ofw_bus_map_intr is called always with the first cells of the interrupt no matter the number of cells specified by #interrupt-cells. > 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. In the Xen device tree, we have an hypervisor node directly attach to the root which contains both MMIO and interrupt used by Xen to communicate with the guest. -- Julien Grall