[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] domain: use PGC_extra domheap page for shared_info

> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Sent: 26 February 2020 11:46
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall
> <julien@xxxxxxx>; Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>; George
> Dunlap <george.dunlap@xxxxxxxxxx>; Ian Jackson
> <ian.jackson@xxxxxxxxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Konrad
> Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>
> 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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.