All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/grants: repurpose command line max options
Date: Tue, 14 Mar 2023 11:25:25 +0100	[thread overview]
Message-ID: <ZBBLlQZLfkRltI9R@Air-de-Roger> (raw)
In-Reply-To: <04bfee08-53e5-49f2-3fb9-440b6861e3f7@suse.com>

On Tue, Mar 14, 2023 at 11:04:21AM +0100, Jan Beulich wrote:
> On 14.03.2023 10:22, Roger Pau Monné wrote:
> > On Mon, Mar 13, 2023 at 05:55:09PM +0100, Jan Beulich wrote:
> >> On 13.03.2023 13:16, Roger Pau Monne wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-command-line.pandoc
> >>> @@ -1232,9 +1232,8 @@ 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 maximum 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.
> >>
> >> dom0less DomU-s do as well, at the very least, also ...
> >>
> >>> @@ -1245,9 +1244,10 @@ Dom0 is using this value for sizing its grant table.
> >>>  
> >>>  > Can be modified at runtime
> >>>  
> >>> -Specify the maximum number of frames to use as part of a domains
> >>> -maptrack array. This value is an upper boundary of the per-domain
> >>> -value settable via Xen tools.
> >>> +Specify the default maximum number of frames to use as part of a domains
> >>> +maptrack array unless a different value is specified at domain creation.
> >>> +
> >>> +Dom0 is using this value for sizing its maptrack array.
> >>
> >> ... here. And even ordinary DomU-s appear to default to that in the
> >> absence of a specific value in the guest config. IOW at the very least
> >> the info you add should not be misleading. Better would be if the pre-
> >> existing info was adjusted at the same time.
> > 
> > Aren't domUs already clearly covered by the sentence:
> > 
> > "Specify the default maximum number of frames to use as part of a domains..."
> 
> Hmm, yes, my attention was caught too much by the Dom0 statement. While ...
> 
> > IMO dom0 needs to be explicitly mentioned because in that case the
> > value provided is not the one used by default, but rather the one that
> > gets used.
> 
> ... explicitly mentioning Dom0 is fine, I still think this needs wording
> differently here, because Dom0 doesn't actively do anything with this
> value (and, as said, it can't even obtain it other than by probing how
> many mappings it can create).
> 
> >> I also wonder about the specific wording down here: While the max grant
> >> table size can indeed be queried, this isn't the case for the maptrack
> >> array. A domain also doesn't need to know its size, so maybe "This value
> >> is used to size all domains' maptrack arrays, unless overridden by their
> >> guest config"?
> > 
> > I think the wording I've added already conveys this meaning:
> > 
> > "Specify the default maximum number of frames to use as part of a domains
> > maptrack array unless a different value is specified at domain creation."
> 
> Well, I mean specifically the Dom0 related statement.
> 
> Also to me "default maximum" reads odd (and slightly ambiguous). Would
> "default upper bound on the number of ..." perhaps be a little better?

So what about using:

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

Note this value is the enforced upper bound for dom0."

And similar for the maptrack option.

Thanks, Roger.


  reply	other threads:[~2023-03-14 10:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 12:16 [PATCH] xen/grants: repurpose command line max options Roger Pau Monne
2023-03-13 16:55 ` Jan Beulich
2023-03-14  9:22   ` Roger Pau Monné
2023-03-14 10:04     ` Jan Beulich
2023-03-14 10:25       ` Roger Pau Monné [this message]
2023-03-14 10:31         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZBBLlQZLfkRltI9R@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.