[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen/grants: repurpose command line max options
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Tue, 14 Mar 2023 16:42:25 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gZ2pS40nOI6xw9QUw+KjuzX2QMDoxv1m7kj2GobSkbo=; b=D9H43711nWZPTk/ifplzKu0Mi5XH2yOnvyqgTfJzaQ/5kj47W0qGUKWREEU4AMKWX4/y6ytxwRgcPVKK7EDC6/TZvSow2sSqT7AElcfcGdMBfcIEOStBHG3skC99nbDTH3x36D4B6vmzS7MU0N0unpAtZQITXDsnsmCoBJMcGnonBJhEmitp43tLpwU+lb8Takys84chRutByb2UFQni7PxeUc33hfoNBmbuyF8rcKDP9dcek3wU0u9HOlzSVrpTWd67urb67SCZwbzpn/u6AYJEsiMK9oHlqxAo6dXAbFxZcfr93KVHXTAn/jaXz7M8MJIetQGbvtdyGK91wL+Gng==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h+W3kUaIJRJ6B9hbcNmAC7zFdnDsRuSL/8q0vOH74TUeWF9KDLzwtMv9dgUjcgLyPDOCD6M6lfOnX0GfdMH4li5bWSMOQRpGJ20abHUaePuVDyjuTiP8MXIfE+s2HpBECVGWJHowuzhZeFHx6fhNcSgPLYkPIR9Q3gA7b1hUYvxeVTuk/MmJLoKMHEcilol9MwUTNjOZv9goWzvfdd7MjnXdDfyukVVGqDmIEYOfV5RMeixoIpawBUZoZkapNf/InrqtEBk+PXDV261PIsmpHg3I3uGfuEzq8IuiJQxG3nfQ2EEi0mJeCaeuOQGf1gujzGzobgtqvksnby2kmGpEIw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 14 Mar 2023 15:42:48 +0000
- Ironport-data: A9a23:VBlx/6IvzFSsixvrFE+RH5QlxSXFcZb7ZxGr2PjKsXjdYENShDVSn DAeCzvSO/2JNjGmKYx/aYrn90wEvZ/Qz9FiHVBlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/rOHvykU7Ss1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpJrfPTwP9TlK6q4mhA5QViPaojUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c5PIHpM8 vAAFAwqawKCuuPt67mhYO9F05FLwMnDZOvzu1lG5BSAVbMMZ8+GRK/Ho9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXKmUE7g7K4/VvpTGLkGSd05C0WDbRUsaNSshP2F6Ru 0rN/njjAwFcP9uaodaA2iv03rCWx3OiAur+EpWmr9tWgnCQwlcSJ0QPaWa/hdK4sWqhDoc3x 0s8v3BGQbIJ3E6hQ8T5Xha4iGWZpRNaUN1Ve8U49QWMx6z88wufQG8eQVZpc8c6vcU7QTgr0 F6hnN7zAzFr9rqPRhq16bO8vT60fy8PIgcqdSICCAcI/dTniIUylQ7UCMZuFravid/4Ei22x CqFxBXSnJ0WhM8Pkq+9olbOhmv0ooCTF1ZpoALKQmii8wV1Ipa/YJCl4kTa6vAGK5uFSl6Gv z4PnM32AP0yMKxhXRelGI0ldIxFLd7cWNEAqTaDx6Ucygk=
- Ironport-hdrordr: A9a23:nMkue6hyy7u9LgXr9+912ykRRnBQXiwji2hC6mlwRA09TyX5ra 2TdTogtSMc6QxhPk3I/OrrBEDuexzhHPJOj7X5eI3SPjUO21HYS72Kj7GSoAEIcheWnoJgPO VbAs1D4bXLZmSS5vyKhDVQfexA/DGGmprY+ts3zR1WPH9Xg3cL1XYJNu6ZeHcGNDWvHfACZe OhDlIsnUvcRZwQBP7LfkUtbqz4iPDgsonpWhICDw5P0njzsdv5gISKaCRxx30lIkly/Ys=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Mar 14, 2023 at 03:59:22PM +0100, Jan Beulich wrote:
> On 14.03.2023 15:45, Roger Pau Monne wrote:
> > Slightly change the meaning of the command line
> > gnttab_max_{maptrack_,}frames: do not use them as upper bounds for the
> > passed values at domain creation, instead just use them as defaults
> > in the absence of any provided value.
> >
> > It's not very useful for the options to be used both as defaults and
> > as capping values for domain creation inputs. The defaults passed on
> > the command line are used by dom0 which has a very different grant
> > requirements than a regular domU. dom0 usually needs a bigger
> > maptrack array, while domU usually require a bigger number of grant
> > frames.
> >
> > The relaxation in the logic for the maximum size of the grant and
> > maptrack table sizes doesn't change the fact that domain creation
> > hypercall can cause resource exhausting, so disaggregated setups
> > should take it into account.
> >
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> albeit perhaps with yet one more wording change (which I'd be happy to
> make while committing, provided you agree):
>
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -1232,11 +1232,11 @@ The usage of gnttab v2 is not security supported on
> > ARM platforms.
> >
> > > Can be modified at runtime
> >
> > -Specify the maximum number of frames which any domain may use as part
> > -of its grant table. This value is an upper boundary of the per-domain
> > -value settable via Xen tools.
> > +Specify the default upper bound on the number of frames which any domain
> > may
> > +use as part of its grant table unless a different value is specified at
> > domain
> > +creation.
> >
> > -Dom0 is using this value for sizing its grant table.
> > +Note this value is the effective upper bound for dom0.
>
> DomU-s created during Xen boot are equally taking this as their effective
> value, aiui. So I'd be inclined to amend this: "... for dom0, and for
> any domU created in the course of Xen booting".
Not really for domUs, as there's a way to pass a different value for
both options in the dt, see create_domUs().
Thanks, Roger.
|
