From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 22/24] tools/libxl: arm: Use an higher value for the GIC phandle Date: Tue, 24 Feb 2015 10:08:51 +0000 Message-ID: <1424772531.27930.291.camel@citrix.com> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-23-git-send-email-julien.grall@linaro.org> <54CA21EE.9050407@linaro.org> <54CA3A33.3070007@linaro.org> <1424702190.27930.120.camel@citrix.com> <54EBA383.2030406@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YQCRw-0002vf-CM for xen-devel@lists.xenproject.org; Tue, 24 Feb 2015 10:10:44 +0000 In-Reply-To: <54EBA383.2030406@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Wei Liu , Stefano Stabellini , Ian Jackson , tim@xen.org, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Mon, 2015-02-23 at 22:02 +0000, Julien Grall wrote: > > On 23/02/2015 14:36, Ian Campbell wrote: > > On Thu, 2015-01-29 at 13:48 +0000, Julien Grall wrote: > >> On 29/01/15 12:28, Stefano Stabellini wrote: > >>> On Thu, 29 Jan 2015, Julien Grall wrote: > >>>> On 29/01/15 11:07, Stefano Stabellini wrote: > >>>>> On Tue, 13 Jan 2015, Julien Grall wrote: > >>>>>> The partial device tree may contains phandle. The Device Tree Compiler > >>>>>> tends to allocate the phandle from 1. > >>>>>> > >>>>>> Reserve the ID 65000 for the GIC phandle. I think we can safely assume > >>>>>> that the partial device tree will never contain a such ID. > >>>>>> > >>>>>> Signed-off-by: Julien Grall > >>>>>> Cc: Ian Jackson > >>>>>> Cc: Wei Liu > >>>>>> > >>>>> > >>>>> Shouldn't we at least check that the partial device tree doesn't contain > >>>>> a conflicting phandle? > >>>> > >>>> I don't think so. This will unlikely happen, and if it happens the guest > >>>> will crash with an obvious error. > >>> > >>> It is good that the error is obvious. > >>> > >>> But how expensive is to check for it? > >> > >> I would have to check the validity of the properties (name + value > >> size). At least the properties "linux,phandle" and "phandle" should be > >> checked. > >> > >> Though I could do in copy_properties but I find it hackish. > > > > Can't you just track the largest phandle ever seen during > > copy_properties and then use N+1 for the GIC? > > Now the we decided to trust the input device tree, it would be easier to > write the code. > > I will give a look. > > > > >>> Think about the poor user that ends up in this situation: the fact that > >>> is unlikely only makes it harder for a user to figure out what to do to > >>> fix it. > >> > >> The poor use will have to write his device tree by hand to hit this > >> error ;). > > > > Or use a new version of dtc which does things differently for some > > reason. > > And you would not be able to get a phandle for the GIC if largest > phandle is too high. > > So the guest won't work correctly. Indeed, filling in a bitmap as you go might be another option, although you'd either need an 8k bitmap (not so bad in userspace) or to realloc as it grows. Ian.