From: "Petr Beneš" <w1benny@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Tamas K Lengyel" <tamas@tklengyel.com>,
"Alexandru Isaila" <aisaila@bitdefender.com>,
"Petre Pircalabu" <ppircalabu@bitdefender.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 4/7] x86: Make the maximum number of altp2m views configurable
Date: Tue, 30 Apr 2024 18:00:13 +0200 [thread overview]
Message-ID: <CAKBKdXjsz_By_nZHDBpzTASSwMQUw61-7UA0YYrSTN+YDivqWQ@mail.gmail.com> (raw)
In-Reply-To: <5600e97e-5d44-4901-a867-b48192e9525f@suse.com>
On Tue, Apr 30, 2024 at 4:27 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -685,6 +685,12 @@ int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
> > return -EINVAL;
> > }
> >
> > + if ( config->max_altp2m > MAX_EPTP )
> > + {
> > + dprintk(XENLOG_INFO, "max_altp2m must be <= %u\n", MAX_EPTP);
> > + return -EINVAL;
> > + }
>
> ... using MAX_EPTP here feels like a layering violation to me. Imo there want
> to be separate constants, tied together with a suitably placed BUILD_BUG_ON().
>
> Furthermore comparisons like this (there are further ones elsewhere) suggest
> there is a (continued) naming issue: A max_ or MAX_ prefix ought to name a
> "maximum valid value", not "number of permitted values". This is not a
> request to alter MAX_EPTP, but one to make sure the new struct fields really
> have matching names and purposes.
Do you have any proposals? I was considering nr_altp2m. Another
question is what it should be named in xl.cfg - also nr_altp2m? I was
too hesitant to name it like that, since there aren't any nr_* fields
currently.
> > --- a/xen/arch/x86/include/asm/domain.h
> > +++ b/xen/arch/x86/include/asm/domain.h
> > @@ -258,11 +258,10 @@ struct paging_vcpu {
> > struct shadow_vcpu shadow;
> > };
> >
> > +#define INVALID_ALTP2M 0xffff
> > +#define MAX_EPTP ((unsigned int)(PAGE_SIZE / sizeof(uint64_t)))
>
> Aiui you add this cast because of the various min() uses. However, besides
> wanting to avoid such casts (or in fact any, whenever possible), I don't
> see why you need to retain all those min(): You bound d->max_altp2m against
> MAX_EPTP during domain creation anyway.
Fair. I considered removing the min()s altogether. I left them in
place because I was too paranoid.
>
> > @@ -28,8 +34,13 @@ altp2m_vcpu_initialise(struct vcpu *v)
> > void
> > altp2m_vcpu_destroy(struct vcpu *v)
> > {
> > + struct domain *d = v->domain;
> > struct p2m_domain *p2m;
> >
> > + /* Skip destruction if no altp2m was used. */
> > + if ( d->max_altp2m == 0 )
> > + return;
>
> ... this one doesn't look quite right: Even if altp2m-s were initialized,
> none may have been used (yet).
Fair. Bad choice of words.
>
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -602,6 +602,8 @@ struct domain
> > unsigned int guest_request_sync : 1;
> > } monitor;
> >
> > + unsigned int max_altp2m; /* Maximum number of altp2m tables */
> > +
> > unsigned int vmtrace_size; /* Buffer size in bytes, or 0 to disable. */
>
> ... this suggest you're confident other architectures will also want
> to support altp2m. Yet nothing like that is said in the description.
> In the absence of that common code should not require touching (much).
Depends on the definition of "want". altp2m patches for arm/aarch64
were sent to Xen some 6 years ago but were unfortunately rejected. I
would very much welcome them.
I have added the field to domain instead of arch_domain simply because
it is not an arch-bound feature - similarly to vmtrace below, which
also doesn't have an equivalent implementation on other archs than x86
(yet).
As far as other comments/nits go - understood.
P.
next prev parent reply other threads:[~2024-04-30 16:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-28 16:52 [PATCH v2 0/7] x86: Make MAX_ALTP2M configurable Petr Beneš
2024-04-28 16:52 ` [PATCH v2 1/7] x86/p2m: Add braces for better code clarity Petr Beneš
2024-04-29 7:07 ` Jan Beulich
2024-04-29 10:26 ` Petr Beneš
2024-04-29 10:27 ` Jan Beulich
2024-04-28 16:52 ` [PATCH v2 2/7] tools/xl: Add max_altp2m parameter Petr Beneš
2024-04-28 16:52 ` [PATCH v2 3/7] docs/man: Add max_altp2m parameter to the xl.cfg manual Petr Beneš
2024-04-28 16:52 ` [PATCH v2 4/7] x86: Make the maximum number of altp2m views configurable Petr Beneš
2024-04-30 14:27 ` Jan Beulich
2024-04-30 16:00 ` Petr Beneš [this message]
2024-05-02 6:19 ` Jan Beulich
2024-04-28 16:52 ` [PATCH v2 5/7] tools/libxl: Activate the max_altp2m feature Petr Beneš
2024-04-28 16:52 ` [PATCH v2 6/7] tools/ocaml: Add max_altp2m parameter Petr Beneš
2024-04-28 16:52 ` [PATCH v2 7/7] x86/hap: Increase the number of initial mempool_size to 1024 pages Petr Beneš
2024-04-30 14:47 ` Jan Beulich
2024-04-30 15:40 ` Petr Beneš
2024-05-02 6:36 ` Jan Beulich
2024-05-02 11:59 ` Petr Beneš
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=CAKBKdXjsz_By_nZHDBpzTASSwMQUw61-7UA0YYrSTN+YDivqWQ@mail.gmail.com \
--to=w1benny@gmail.com \
--cc=aisaila@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=ppircalabu@bitdefender.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tamas@tklengyel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).