Re: [Xen-devel] [PATCH-for-4.13 v7] Rationalize max_grant_frames and max_maptrack_frames handling

[Wei Liu <wl@xxxxxxx>]

On Fri, Nov 29, 2019 at 05:53:39PM +0000, George Dunlap wrote:
> 
> 
> > On Nov 29, 2019, at 5:44 PM, Wei Liu <wl@xxxxxxx> wrote:
> > 
> > On Fri, Nov 29, 2019 at 05:36:11PM +0000, Wei Liu wrote:
> >> On Fri, Nov 29, 2019 at 05:24:45PM +0000, Paul Durrant wrote:
> >>> From: George Dunlap <george.dunlap@xxxxxxxxxx>
> >>> 
> >>> Xen used to have single, system-wide limits for the number of grant
> >>> frames and maptrack frames a guest was allowed to create. Increasing
> >>> or decreasing this single limit on the Xen command-line would change
> >>> the limit for all guests on the system.
> >>> 
> >>> Later, per-domain limits for these values was created. The system-wide
> >>> limits became strict limits: domains could not be created with higher
> >>> limits, but could be created with lower limits. However, that change
> >>> also introduced a range of different "default" values into various
> >>> places in the toolstack:
> >>> 
> >>> - The python libxc bindings hard-coded these values to 32 and 1024,
> >>>  respectively
> >>> - The libxl default values are 32 and 1024 respectively.
> >>> - xl will use the libxl default for maptrack, but does its own default
> >>>  calculation for grant frames: either 32 or 64, based on the max
> >>>  possible mfn.
> >>> 
> >>> These defaults interact poorly with the hypervisor command-line limit:
> >>> 
> >>> - The hypervisor command-line limit cannot be used to raise the limit
> >>>  for all guests anymore, as the default in the toolstack will
> >>>  effectively override this.
> >>> - If you use the hypervisor command-line limit to *reduce* the limit,
> >>>  then the "default" values generated by the toolstack are too high,
> >>>  and all guest creations will fail.
> >>> 
> >>> In other words, the toolstack defaults require any change to be
> >>> effected by having the admin explicitly specify a new value in every
> >>> guest.
> >>> 
> >>> In order to address this, have grant_table_init treat negative values
> >>> for max_grant_frames and max_maptrack_frames as instructions to use the
> >>> system-wide default, and have all the above toolstacks default to passing
> >>> -1 unless a different value is explicitly configured.
> >>> 
> >>> This restores the old behavior in that changing the hypervisor 
> >>> command-line
> >>> option can change the behavior for all guests, while retaining the ability
> >>> to set per-guest values.  It also removes the bug that reducing the
> >>> system-wide max will cause all domains without explicit limits to fail.
> >>> 
> >>> NOTE: - The Ocaml bindings require the caller to always specify a value,
> >>>        and the code to start a xenstored stubdomain hard-codes these to 4
> >>>   and 128 respectively; this behavour will not be modified.
> >>> 
> >>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> >>> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> >>> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> 
> Does this win some kind of award for “most collaborative patch”?

In terms of numbers of SoB, not yet. I've seen patch(es) with three
SoBs.

Someone should've left a typo in somewhere so that I can fix it and put
my SoB in. That may make this patch the most collaborative patch I know
of. :-)

Wei.

> 
>  -George
> 

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