> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 06 March 2020 13:36 > To: Paul Durrant <xadimg...@gmail.com> > Cc: sstabell...@kernel.org; jul...@xen.org; volodymyr_babc...@epam.com; > w...@xen.org; > konrad.w...@oracle.com; andrew.coop...@citrix.com; ian.jack...@eu.citrix.com; > george.dun...@citrix.com; xen-devel@lists.xenproject.org; 'David Woodhouse' > <dw...@infradead.org> > Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for shared_info > > On 06.03.2020 14:26, Paul Durrant wrote: > >> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Jan > >> Beulich > >> Sent: 06 March 2020 13:24 > >> > >> On 06.03.2020 14:13, Paul Durrant wrote: > >>> My aim is to make the separation abundantly obvious by getting rid > >>> of shared xenheap pages (for non-system domains at least) but I > >>> can't do that before converting shared_info and grant shared/status > >>> frames to domheap. > >> > >> Following David's various replies - instead of going this route of > >> replacing the sharing of xenheap pages by different logic, the > >> same ought to be achievable by making the backing allocations come > >> from the correct pool? > >> > > > > I still prefer the simplification of not having to clean up the > > shared xenheap page list in domain_kill() so IMO it is still worth > > it for that alone. > > I don't see anything very special with the cleaning up in > domain_kill() / domain_relinquish_resources(). What I'd view as > more desirable in this regard is the general fact of needing > two lists. But you realize there's a downside to this as well? > dump_pageframe_info() will reliably show _all_ Xen heap pages > associated with a domain, but it will only ever show up to 10 > pages on ->page_list for a domain that's not already being > cleaned up.
That's not much of a downside though I don't think. The xenheap (or PGC_extra domheap pages) are 'special' and so info about them ought to be available via an alternate dump function anyway (and if not already, it can be added). Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
