Re: [PATCH 00/16] Remove the direct map

[Hongyan Xia <hx242@xxxxxxx>]

On Fri, 2020-05-01 at 12:07 +0000, Wei Liu wrote:
> On Thu, Apr 30, 2020 at 09:44:09PM +0100, Hongyan Xia wrote:
> > From: Hongyan Xia <hongyxia@xxxxxxxxxx>
> > 
> > This series depends on Xen page table domheap conversion:
> > 
https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg01374.html
> > .
> > 
> > After breaking the reliance on the direct map to manipulate Xen
> > page
> > tables, we can now finally remove the direct map altogether.
> > 
> > This series:
> > - fixes many places that use the direct map incorrectly or assume
> > the
> >   presence of an always-mapped direct map in a wrong way.
> > - includes the early vmap patches for global mappings.
> > - initialises the mapcache for all domains, disables the fast path
> > that
> >   uses the direct map for mappings.
> > - maps and unmaps xenheap on-demand.
> > - adds a boot command line switch to enable or disable the direct
> > map.
> > 
> > This previous version was in RFC state and can be found here:
> > 
https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02647.html
> > ,
> > which has since been broken into small series.
> 
> OOI have you done any performance measurements?
> 
> Seeing that now even guest table needs mapping / unmapping during
> restore, I'm curious to know how that would impact performance.

I actually have a lot of performance numbers but unfortunately on an
older version of Xen, not staging. I need to evaluate it again before
coming back to you. As you suspected, one strong signal from the
performance results is definitely the impact of walking guest tables.
For EPT, mapping and unmapping 20 times is no fun. This shows up in
micro-benchmarks, although larger benchmarks tend to be fine.

My question is, do we care about hiding EPT? I think it is fine to just
use xenheap pages (or any other form which does the job) so that we go
down from 20 mappings to only 4. I have done this hack with EPT and saw
significantly reduced impact for HVM guests in micro-benchmarks.

Hongyan