Hi julien > -----Original Message----- > From: Julien Grall <jul...@xen.org> > Sent: Wednesday, June 9, 2021 6:47 PM > To: Bertrand Marquis <bertrand.marq...@arm.com> > Cc: Stefano Stabellini <sstabell...@kernel.org>; Julien Grall > <julien.grall....@gmail.com>; Penny Zheng <penny.zh...@arm.com>; xen- > de...@lists.xenproject.org; Wei Chen <wei.c...@arm.com>; nd > <n...@arm.com> > 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 <jul...@xen.org > >> <mailto:jul...@xen.org>> 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
