[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 01/10] xen/arm: introduce domain on Static Allocation

  • To: Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Penny Zheng <Penny.Zheng@xxxxxxx>
  • Date: Tue, 15 Jun 2021 06:08:00 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kmvLMnUyXKkeR1agEijox6oairFBDgNT7zNDdvTaZss=; b=Pj1lTERb8d1E+kUlMx7ILnLDZGB0lhZBgWwFNhN6kNEmbo4ZLEEFV7S9a8yamm/cGcbInsidSAkMjZlqO6Ea1B0kfO9RsNQgfWOCkR2CTF7oHoqT1IONdOBpiKUv9uP5ZwB+R5+CaP356TtaOdfXnhBmHB9a7z9MrDD9q3xsrYWpbwfyHllEnCC9c89nSGGU8tvST/XKwAEIym6o2wqnjFW1yiDlZFfHXvaix4XtiIU2IPWx05gx5muoSeblgKCmzFWT2RIcKbRxlC4/IoE84byqGyQpokADiD6PVUU2PfIrY5kNn05r0AKNbIq7n80c7HGq4WniEDenf1/4V3gXwA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R5FgR+lT2ndvnlB70+E7UDahJhpAuf1FQQrDQQoHkPTVjKfmBacI/gWo7s6U79QfyvfZMioevm3lz4bqrU9irI9annkajcPbaupfEDA79/9zJmAJD+pagUGCSLg/x16WheH4VwOkNsbPEB4kDGq4OwzphID7jWCSeNGtGwJ9bl8/IDSqsIwIie6ep5kA9Ikn70XTXd1wHBB5BR3IUkYjJEPPMAR2ptMt+WtEFM4h/BFNWVThKfXmw5Zcsi2VJrVCVFwjItJYB7ga7YCW0Pq9Ji1pPKxBzD0X44MA+0WmdP5T80mk8RLDvg4UKXuLi9QxY6aGc0sbXHyyZhIByOp84Q==
  • Authentication-results-original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien.grall.oss@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, nd <nd@xxxxxxx>
  • Delivery-date: Tue, 15 Jun 2021 06:08:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Thread-topic: [PATCH 01/10] xen/arm: introduce domain on Static Allocation

Hi julien

> -----Original Message-----
> From: Julien Grall <julien@xxxxxxx>
> Sent: Wednesday, June 9, 2021 6:47 PM
> To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall
> <julien.grall.oss@xxxxxxxxx>; Penny Zheng <Penny.Zheng@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Wei Chen <Wei.Chen@xxxxxxx>; nd
> <nd@xxxxxxx>
> Subject: Re: [PATCH 01/10] xen/arm: introduce domain on Static Allocation
> On 09/06/2021 10:56, Bertrand Marquis wrote:
> > Hi All,
> Hi,
> >> On 7 Jun 2021, at 19:09, Julien Grall <julien@xxxxxxx
> >> <mailto:julien@xxxxxxx>> wrote:
> >> Feel free to propose one. I suggested to use /reserved-memory because
> >> this is the approach that makes the most sense to me (see my reply above).
> >>
> >> TBH, even after your explanation, I am still a bit puzzled into why
> >> /reserved-memory cannot be leveraged to exclude domain region from
> >> the hypervisor allocator.
> >
> > I really tend to think that the original solution from Penny is for
> > now the easiest and simplest to document.
> I can live with Penny's solution so long we don't duplicate the parsing and we
> don't create new datastructure in Xen for the new type of reserved memory.
> However...

Just to confirm what I understand here, you are not only worrying about the 
duplication code imported in
dt_unreserved_regions, but also must introducing another path in func 
early_scan_node to parse my first implementation
"xen,static-mem = <...>", right?

On duplication code part, I could think of a way to extract common codes to 
fix, but for introducing another new path to parse,
FWIT, it is inevitable if not re-using reserved-memory. ;/

> > In the long term, using directly memory and giving in it the address
> > range directly is the most natural solution but that would clash with
> > the current usage for it.
> ... we are already going to have quite some churn to support the system
> device-tree. So I don't want yet another binding to be invented in a few
> months time.
> IOW, the new binding should be a long term solution rather than a temporary
> one to fill the gap until we agree on what you call "domain v2".
> Cheers,
> --


> Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.