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

[Penny Zheng <Penny.Zheng@xxxxxxx>]

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,
> 
> --

Cheers

Penny
> Julien Grall