From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
Jason Andryuk <jason.andryuk@amd.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Teddy Astie <teddy.astie@vates.tech>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.22 v2] xen/x86: Change stub page allocation/free
Date: Fri, 12 Jun 2026 09:44:27 +0200 [thread overview]
Message-ID: <aiu42_rcIxZTvbXy@macbook.local> (raw)
In-Reply-To: <0a2e670e-432b-4297-8166-42a1bace6659@suse.com>
On Fri, Jun 12, 2026 at 09:40:03AM +0200, Jan Beulich wrote:
> On 11.06.2026 16:21, Roger Pau Monne wrote:
> > @@ -641,41 +642,62 @@ static int do_boot_cpu(int apicid, int cpu)
> > return rc;
> > }
> >
> > -#define STUB_BUF_CPU_OFFS(cpu) (((cpu) & (STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE)
> > +/* Dynamically allocated, indexed by CPU. Store physical address of stubs. */
> > +static paddr_t *__ro_after_init stubs;
> >
> > -unsigned long alloc_stub_page(unsigned int cpu, unsigned long *mfn)
> > +static bool assign_stub_page(unsigned int cpu)
> > {
> > unsigned long stub_va;
> > - struct page_info *pg;
> > + paddr_t addr = stubs[cpu];
> >
> > - BUILD_BUG_ON(STUBS_PER_PAGE & (STUBS_PER_PAGE - 1));
> > -
> > - if ( *mfn )
> > - pg = mfn_to_page(_mfn(*mfn));
> > - else
> > + if ( addr == INVALID_PADDR )
> > {
> > - nodeid_t node = cpu_to_node(cpu);
> > - unsigned int memflags = node != NUMA_NO_NODE ? MEMF_node(node) : 0;
> > + nodeid_t nid = cpu_to_node(cpu);
> >
> > - pg = alloc_domheap_page(NULL, memflags);
> > - if ( !pg )
> > - return 0;
> > + /*
> > + * Attempt to use the same page as the previous CPU if possible,
> > + * otherwise allocate a new one.
> > + */
> > + if ( cpu && nid == cpu_to_node(cpu - 1) &&
> > + PAGE_OFFSET(stubs[cpu - 1] + STUB_BUF_SIZE) )
> > + addr = stubs[cpu - 1] + STUB_BUF_SIZE;
>
> Isn't this path also going to be taken if stubs[cpu - 1] is still INVALID_PADDR?
> That may be a purely hypothetical case right now, but imo would better be
> covered right away.
Yes, indeed I was assuming that stubs[cpu - 1] would always be
populated, which it's the case currently, but you are right that it's
trivial to also take this scenario into account here.
Thanks, Roger.
prev parent reply other threads:[~2026-06-12 7:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 14:21 [PATCH for-4.22 v2] xen/x86: Change stub page allocation/free Roger Pau Monne
2026-06-11 17:26 ` Jason Andryuk
2026-06-12 7:40 ` Jan Beulich
2026-06-12 7:44 ` Roger Pau Monné [this message]
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=aiu42_rcIxZTvbXy@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=jason.andryuk@amd.com \
--cc=jbeulich@suse.com \
--cc=oleksii.kurochko@gmail.com \
--cc=teddy.astie@vates.tech \
--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.