From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B7FEC47096 for ; Thu, 3 Jun 2021 22:07:37 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A7ED8613FF for ; Thu, 3 Jun 2021 22:07:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7ED8613FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.136568.253143 (Exim 4.92) (envelope-from ) id 1lovUo-0004AP-V1; Thu, 03 Jun 2021 22:07:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 136568.253143; Thu, 03 Jun 2021 22:07:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lovUo-0004AI-Rx; Thu, 03 Jun 2021 22:07:22 +0000 Received: by outflank-mailman (input) for mailman id 136568; Thu, 03 Jun 2021 22:07:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lovUn-0004AC-HU for xen-devel@lists.xenproject.org; Thu, 03 Jun 2021 22:07:21 +0000 Received: from mail-ej1-x629.google.com (unknown [2a00:1450:4864:20::629]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f75b3ef9-fe9b-41c5-b618-96d8faa1fb97; Thu, 03 Jun 2021 22:07:20 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id k7so11417441ejv.12 for ; Thu, 03 Jun 2021 15:07:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f75b3ef9-fe9b-41c5-b618-96d8faa1fb97 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fTwcjmwhNEADbX/Ob8xBzd2SXmTk5gXlTEv1cMtlxa0=; b=pAjZ0ZoXVUivt/xg82DQQU2Xo+JPZqnyDiCwTeA2vIs87m+etMYvbgKdBfJSmWIWLT TtCr2oOpEflb6YL/P0NwNcwubka2GkHlTuPLIMxZ4RZQDmHKsk9BG+Sok//rifxrp0gF eksmHx0X5wIyK7KcAWBtYncR0/EnM7HiGb6HtUDcN7pUEV1IzmdtnfppHCvUhm3Ib95W 1x1PIm28tfZHxV3jNS5aFmujnXuwvUcvD5l+oySrgxJk4WSiMDO7tcD73bGE1sXBFCi3 S5EdPOJSXctbsoiKCyBGCaxldabFHcaN7PqYfPfYjpGtwKrDW3iGaEsyaKxV/B/BzThr 7veg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fTwcjmwhNEADbX/Ob8xBzd2SXmTk5gXlTEv1cMtlxa0=; b=Th+vkHRKu1ljJD5PIG6/YaJF4M5R65GvgeCQ0gQQ8ys48zjaApYNQjIzmg/u97s+4c GRod8IN0FvYW4DVEOFEcFtc8KZghZISl4lGvaPAjofaz03kUpv+CePvmvturp9jIkzsZ bSxFK1lGAI+6NTdZoeH+vK+MkicIWJouHwuq7L0xANdqrSvbiuRfil51YbBkLIDoi68K AP12eZwbFu+zGk4jTBnXWAmAG8uiyTVV1/LlTBv0W6Ycc23SYEgwJP5b+Z9+ZRPnbhNL tqV0oJRB61r8BnGNYgWp/e0XuxAZwO0IqUnw/fwcgHaR/4IsE0G25yVOsTGiS2BKOQAQ mW8w== X-Gm-Message-State: AOAM5317fvZkGmVjSWNM8eWezQRtnPC971hRvwv0/mNl2frxEA1NiEHe r8A5kafTotC/9jx1b1Qfk0nkpdQZm1qVrbLE4gY= X-Google-Smtp-Source: ABdhPJz8dlimJ5xx0btkf+kXPsCHFyqiefzOTAPlzlinf2CIqkvR5O2iysZrIMOV1oLUYyXJBfPfJtu9HdCVuazcllk= X-Received: by 2002:a17:906:b10e:: with SMTP id u14mr1228007ejy.546.1622758039673; Thu, 03 Jun 2021 15:07:19 -0700 (PDT) MIME-Version: 1.0 References: <20210518052113.725808-1-penny.zheng@arm.com> <20210518052113.725808-2-penny.zheng@arm.com> <66e32065-ea2d-d000-1a70-e5598a182b6a@xen.org> <14fb6fe4-c293-6994-8cbc-872d3bd8a3ac@xen.org> <4251e0e2-fb53-b8a3-0323-f4ce892cf21e@xen.org> In-Reply-To: From: Julien Grall Date: Thu, 3 Jun 2021 23:07:08 +0100 Message-ID: Subject: Re: [PATCH 01/10] xen/arm: introduce domain on Static Allocation To: Stefano Stabellini Cc: Penny Zheng , "xen-devel@lists.xenproject.org" , Bertrand Marquis , Wei Chen , nd Content-Type: text/plain; charset="UTF-8" Hi, On Thu, 3 Jun 2021 at 22:33, Stefano Stabellini wrote: > On Thu, 3 Jun 2021, Julien Grall wrote: > > On 02/06/2021 11:09, Penny Zheng wrote: > > > I could not think a way to fix it properly in codes, do you have any > > > suggestion? Or we just put a warning in doc/commits. > > > > The correct approach is to find the parent of staticmemdomU1 (i.e. > > reserved-memory) and use the #address-cells and #size-cells from there. > > Julien is right about how to parse the static-memory. > > But I have a suggestion on the new binding. The /reserved-memory node is > a weird node: it is one of the very few node (the only node aside from > /chosen) which is about software configurations rather than hardware > description. > > For this reason, in a device tree with multiple domains /reserved-memory > doesn't make a lot of sense: for which domain is the memory reserved? IHMO, /reserved-memory refers to the memory that the hypervisor should not touch. It is just a coincidence that most of the domains are then passed through to dom0. This also matches the fact that the GIC, /memory is consumed by the hypervisor directly and not the domain.. > > This was one of the first points raised by Rob Herring in reviewing > system device tree. > > So the solution we went for is the following: if there is a default > domain /reserved-memory applies to the default domain. Otherwise, each > domain is going to have its own reserved-memory. Example: > > domU1 { > compatible = "xen,domain"; > #address-cells = <0x1>; > #size-cells = <0x1>; > cpus = <2>; > > reserved-memory { > #address-cells = <2>; > #size-cells = <2>; > > static-memory@0x30000000 { > compatible = "xen,static-memory-domain"; > reg = <0x0 0x30000000 0x0 0x20000000>; > }; > }; > }; This sounds wrong to me because the memory is reserved from the hypervisor PoV not from the domain. IOW, when I read this, I think the memory will be reserved in the domain. > > So I don't think we want to use reserved-memory for this, either > /reserved-memory or /chosen/domU1/reserved-memory. Instead it would be > good to align it with system device tree and define it as a new property > under domU1. Do you have any formal documentation of the system device-tree? > > In system device tree we would use a property called "memory" to specify > one or more ranges, e.g.: > > domU1 { > memory = <0x0 0x500000 0x0 0x7fb00000>; > > Unfortunately for xen,domains we have already defined "memory" to > specify an amount, rather than a range. That's too bad because the most > natural way to do this would be: > > domU1 { > size = ; > memory = ; > > When we'll introduce native system device tree support in Xen we'll be > able to do that. For now, we need to come up with a different property. > For instance: "static-memory" (other names are welcome if you have a > better suggestion). > > We use a new property called "static-memory" together with > #static-memory-address-cells and #static-memory-size-cells to define how > many cells to use for address and size. > > Example: > > domU1 { > #static-memory-address-cells = <2>; > #static-memory-size-cells = <2>; > static-memory = <0x0 0x500000 0x0 0x7fb00000>; This is pretty similar to what Penny suggested. But I dislike it because of the amount of code that needs to be duplicated with the reserved memory. Cheers,