Re: [PATCH v2] gnttab: defer allocation of status frame tracking array

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/12/2020 15:13, Jan Beulich wrote:
> This array can be large when many grant frames are permitted; avoid
> allocating it when it's not going to be used anyway, by doing this only
> in gnttab_populate_status_frames().
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v2: Defer allocation to when a domain actually switches to the v2 grant
>     API.

I see this as a backwards step.  It turns a build-time -ENOMEM into a
runtime -ENOMEM, and if you recall from one of the XSAs, the Windows PV
drivers will BUG() if set_version fails.  (Yes - this is dumb behaviour,
but it is in the field now.)

It is the toolstack's responsibility to not over-extend the capabilities
of the host, but this is impossible to do with behaviour like this. 
Failing at domain creation time is a whole lot less bad for the system
as a whole.

Longer term, allocations like this ought to come from some per-domain
pool (possibly not shared with the shadow memory pool), which can be
sized suitably at create time.

This is one of the points behind introducing dmalloc()/etc in the
fault-injection series.  At the moment, we have absolutely no clue what
the memory overhead of a domain is in Xen.  It is impossible to
calculate how many VMs will fit on a host, because the only way you can
answer the question is to attempt to create them all.

Understanding how much memory a domain actually takes is the first
step.  Creating a plausible bound is the second step, and that will be
of substantial use to higher level management software.

~Andrew