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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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