> -----Original Message----- > From: Andrew Cooper <andrew.coop...@citrix.com> > Sent: 26 February 2020 11:46 > To: Durrant, Paul <pdurr...@amazon.co.uk>; xen-devel@lists.xenproject.org > Cc: Stefano Stabellini <sstabell...@kernel.org>; Julien Grall > <jul...@xen.org>; Volodymyr Babchuk <volodymyr_babc...@epam.com>; George > Dunlap <george.dun...@citrix.com>; Ian Jackson > <ian.jack...@eu.citrix.com>; Jan Beulich <jbeul...@suse.com>; Konrad > Rzeszutek Wilk <konrad.w...@oracle.com>; Wei Liu <w...@xen.org> > Subject: Re: [PATCH 2/2] domain: use PGC_extra domheap page for > shared_info > > On 25/02/2020 09:53, Paul Durrant wrote: > > There's no particular reason shared_info need use a xenheap page. >
Ok, 'particular' is too vague, agreed. I'll elaborate. > ? > > There are a number of ABI-critical reasons, not least the evtchn_pending > field which Xen needs to write. > I do address this specifically in the commit comment. "ASSERTions are added before apparently vulnerable dereferences in the event channel code. These should not be hit because domain_kill() calls evtchn_destroy() before calling domain_relinquish_resources() but are added to catch any future re-ordering." > I can see what you're trying to do, and it looks fine in principle, but > the commit message isn't remotely accurate. Remember that you are in > the process of changing the meaning/usage of the xenheap - preexiting > uses conform to the old meaning, where the sole distinction between > domheap and xenheap pages was whether Xen required a virtual mapping or > not. The answer is "absolutely yes" for the shared info page. > Was that the case? I haven't mined to find when map_domain_page() was introduced. At that point, of course, any strict 'being virtually mapped' distinction between xenheap and domheap was rendered inaccurate. Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
