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

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



> -----Original Message-----
> From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
> Sent: 06 March 2020 13:16
> To: Jan Beulich <jbeulich@xxxxxxxx>; Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> Cc: julien@xxxxxxx; andrew.cooper3@xxxxxxxxxx; sstabellini@xxxxxxxxxx; 
> konrad.wilk@xxxxxxxxxx;
> Volodymyr_Babchuk@xxxxxxxx; ian.jackson@xxxxxxxxxxxxx; wl@xxxxxxx; 
> george.dunlap@xxxxxxxxxx; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [EXTERNAL][PATCH 2/2] domain: use PGC_extra domheap page for 
> shared_info
> 
> On Fri, 2020-03-06 at 14:10 +0100, Jan Beulich wrote:
> > Establishing of what the new separation rule and mechanism is going
> > to be (no matter how the two resulting pieces are going to be
> > named).
> 
> Paul's opinion seemed to be that with secret hiding coming along and
> destroying the "xenheap is mapped anyway" assumption, the benefit of
> allocating a xenheap page and then mapping it to a guest is basically
> gone *anyway*, so that part at least made a viable cleanup regardless
> of the overall direction.

Indeed, that is my opinion. The distinction between a mapped domheap page and a 
xenheap page basically goes away with secret hiding since the direct map is 
basically gone so, given that it helps simplify LU *and* gets rid of the domain 
xenheap list (and hence the somewhat subtle processing of that list in 
domain_kill()), getting rid of shared xenheap pages seems like a useful thing 
to do.

  Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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