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

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

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

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.


Xen-devel mailing list



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