From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>
Subject: Re: [PATCH v2] domain: skip more stuff for idle's vCPU-s in vcpu_create()
Date: Tue, 17 Feb 2026 12:46:29 +0100 [thread overview]
Message-ID: <aZRVFVXYKzQmt3Q8@Mac.lan> (raw)
In-Reply-To: <a0e47cf7-91f0-471e-b6b8-6554f496190f@suse.com>
On Tue, Feb 17, 2026 at 12:17:35PM +0100, Jan Beulich wrote:
> On 17.02.2026 12:04, Roger Pau Monné wrote:
> > On Mon, Feb 16, 2026 at 04:54:30PM +0100, Jan Beulich wrote:
> >> Nothing hypercall-related needs setting up there. Nor do we need to
> >> check whether the idle domain is shutting down - it never will.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>
> Thanks.
>
> >> @@ -516,7 +516,8 @@ struct vcpu *vcpu_create(struct domain *
> >> }
> >>
> >> /* Must be called after making new vcpu visible to for_each_vcpu(). */
> >> - vcpu_check_shutdown(v);
> >> + if ( !is_idle_domain(d) )
> >> + vcpu_check_shutdown(v);
> >
> > I would possibly leave this as-is. I agree that the idle domain will
> > never shut down, but it's possibly best to needlessly call into
> > vcpu_check_shutdown() for the idle domain rather than adding the extra
> > conditional for the common case?
>
> I'd prefer to keep it conditional: Calling the function for the idle
> domain gives a wrong impression, plus it may be the only one where the
> shutdown lock is used for that domain. We may want to make lock init
> conditional in domain_create() as well (possibly with other things we
> needlessly do for idle or more generally system domains).
I've been thinking about this, and I'm not sure whether it's the best
approach to avoid initializing locks or lists for the idle
vCPUs/domain.
It's certainly good to avoid initializing stuff that consumes memory
or other resources, but skipping plain initialization (iow: setting of
values) of fields that are in the respective structs seems dangerous
to a certain degree. If for whatever reason we end up with stray
calls from the idle vCPUs/domain into functions that use those fields
it's likely safer to have them initialized, rather than tripping into
some uninitialized pointer or deadlock trying to acquire and
uninitiated lock.
Thanks, Roger.
next prev parent reply other threads:[~2026-02-17 11:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 15:54 [PATCH v2] domain: skip more stuff for idle's vCPU-s in vcpu_create() Jan Beulich
2026-02-17 11:04 ` Roger Pau Monné
2026-02-17 11:17 ` Jan Beulich
2026-02-17 11:46 ` Roger Pau Monné [this message]
2026-02-17 12:58 ` 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=aZRVFVXYKzQmt3Q8@Mac.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.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.