From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.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: Mon, 13 Mar 2023 17:55:09 +0100 [thread overview]
Message-ID: <2bcd9829-498b-228a-2a86-67f8c6e859aa@suse.com> (raw)
In-Reply-To: <20230313121632.86789-1-roger.pau@citrix.com>
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.
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"?
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1956,18 +1956,15 @@ int grant_table_init(struct domain *d, int max_grant_frames,
> return -EINVAL;
> }
>
> - /* Default to maximum value if no value was specified */
> + /* Apply defaults if no value was specified */
> if ( max_grant_frames < 0 )
> max_grant_frames = opt_max_grant_frames;
> if ( max_maptrack_frames < 0 )
> max_maptrack_frames = opt_max_maptrack_frames;
>
> - if ( max_grant_frames < INITIAL_NR_GRANT_FRAMES ||
> - max_grant_frames > opt_max_grant_frames ||
> - max_maptrack_frames > opt_max_maptrack_frames )
> + if ( max_grant_frames < INITIAL_NR_GRANT_FRAMES )
> {
> - dprintk(XENLOG_INFO, "Bad grant table sizes: grant %u, maptrack %u\n",
> - max_grant_frames, max_maptrack_frames);
> + dprintk(XENLOG_INFO, "Bad grant table size %u\n", max_grant_frames);
> return -EINVAL;
> }
I think I agree with the relaxation done here, but I also think this not
introducing security concerns wants spelling out in the description: My
understanding is that even in disaggregated environments we assume only
fully privileged entities can create domains.
Jan
next prev parent reply other threads:[~2023-03-13 16:55 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 [this message]
2023-03-14 9:22 ` Roger Pau Monné
2023-03-14 10:04 ` Jan Beulich
2023-03-14 10:25 ` Roger Pau Monné
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=2bcd9829-498b-228a-2a86-67f8c6e859aa@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--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.