[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 3/6] x86 / pv: do not treat PGC_extra pages as RAM
> -----Original Message----- > From: Jan Beulich <jbeulich@xxxxxxxx> > Sent: 10 March 2020 15:13 > To: paul@xxxxxxx > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; 'Paul Durrant' <pdurrant@xxxxxxxxxx>; > 'Andrew Cooper' > <andrew.cooper3@xxxxxxxxxx>; 'Wei Liu' <wl@xxxxxxx>; 'Roger Pau Monné' > <roger.pau@xxxxxxxxxx> > Subject: Re: [PATCH v5 3/6] x86 / pv: do not treat PGC_extra pages as RAM > > On 10.03.2020 16:05, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich <jbeulich@xxxxxxxx> > >> Sent: 10 March 2020 14:59 > >> > >> In reply to patch 6 I did suggest to > >> have a separate list, but without taking these pages off > >> d->page_list, > > > > How would that work without adding an extra page_list_entry into struct > > page_info? > > As said there, it'd be a singly linked list using a __pdx_t > field just like there already is with "next_shadow", i.e. > you'd add another union member "next_extra" or some such. Of > course the list shouldn't grow too long, or else insertion > and removal may become a bottleneck. Not sure how well this > would fit Arm, though; maybe they wouldn't need this, but > that depends on whether the list would be used for purposes > beyond dumping. > That seems more obscure and bug-prone than an extra list head in struct domain. I'd really prefer to stick with that even if it does make things a little more ugly until xenpage_list goes away. Paul _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |