Re: [Xen-devel] Reducing or removing direct map from xen (was Re: Ongoing/future speculative mitigation work)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Feb 22, 2019 at 05:06:03AM -0700, Jan Beulich wrote:
> >>> On 22.02.19 at 12:50, <wei.liu2@xxxxxxxxxx> wrote:
> > On Fri, Feb 22, 2019 at 04:48:09AM -0700, Jan Beulich wrote:
> >> >>> On 20.02.19 at 18:08, <wei.liu2@xxxxxxxxxx> wrote:
> >> > On Wed, Feb 20, 2019 at 01:09:56PM +0000, Wei Liu wrote:
> >> > [...]
> >> >> I think under-allocate-then-map looks plausible. xmalloc will need
> >> >> to allocate pages, put them into an array and call __vmap on that array
> >> >> directly.
> >> > 
> >> > The biggest issue with this approach is that we now need an array of
> >> > 1UL<<MAX_ORDER to accommodate mfns. Back of envelope calculation: on x86
> >> > this is going to be (1UL<<20)*8 bytes long. This is not feasible.
> >> 
> >> Are we really calling xmalloc() with any number nearly this big?
> > 
> > In practice, I don't think so. What do you think is a sensible limit?
> 
> I'm afraid you won't like the answer: Whatever the biggest chunk is
> we currently allocate anywhere. Perhaps, e.g. if there's a single big
> "violator", changing some code to reduce the upper bound might be
> desirable.
> 
> In general there shouldn't be any going beyond one page once we've
> completed booting. Several years back I think I had managed to
> replace most (all?) higher order xmalloc()-s. So another option might
> be to allow up to MAX_ORDER by way of some init-only mechanism,
> and later allow only up to single page chunks.
> 

Think about it, if you have done the work to remove high order
allocations, removing this optimisation is the easiest thing to do and
wouldn't make things worse, isn't it?

Wei.

> Jan
> 
> 

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