From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Jan Beulich" <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] xen/page_alloc: Simplify domain_adjust_tot_pages
Date: Tue, 11 Mar 2025 09:46:06 +0000 [thread overview]
Message-ID: <D8DCAEVQKQFE.2W7VAZ1VZ9LZW@cloud.com> (raw)
In-Reply-To: <6070a7b3-4d1d-4db9-a812-5887de129aa1@suse.com>
On Wed Mar 5, 2025 at 1:39 PM GMT, Jan Beulich wrote:
> > It's all quite perverse. Fortunately, looking at adjacent claims-related code
> > xl seems to default to making a claim prior to populating the physmap and
> > cancelling the claim at the end of the meminit() hook so this is never a real
> > problem.
> >
> > This tells me that the logic intent is to force early failure of
> > populate_physmap and nothing else. It's never active by the time ballooning or
> > memory exchange matter at all.
>
> Ah yes, this I find more convincing. (Oddly enough this is all x86-only code.)
Should I take this as an "ack" to the general plan of early returning on pages
<=0? I have a series pending that relies on it (the v2 of this[1]). And would
rather defer its sending until this one get some form of nod. Otherwise I'll
integrate it in the other series so I can at least reduce remove dependencies
between things in-flight.
Cheers,
Alejandro
[1] https://lore.kernel.org/xen-devel/20250304111000.9252-1-alejandro.vallejo@cloud.com/
next prev parent reply other threads:[~2025-03-11 9:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 13:27 [PATCH] xen/page_alloc: Simplify domain_adjust_tot_pages Alejandro Vallejo
2025-02-24 14:49 ` Alejandro Vallejo
2025-02-26 14:05 ` Jan Beulich
2025-02-27 14:36 ` Alejandro Vallejo
2025-03-05 10:49 ` Jan Beulich
2025-03-05 13:22 ` Alejandro Vallejo
2025-03-05 13:39 ` Jan Beulich
2025-03-05 14:55 ` Alejandro Vallejo
2025-03-11 9:46 ` Alejandro Vallejo [this message]
2025-03-11 10:06 ` Jan Beulich
2025-02-26 14:18 ` Roger Pau Monné
2025-02-26 13:56 ` Roger Pau Monné
2025-02-26 14:08 ` Jan Beulich
2025-02-26 14:28 ` Roger Pau Monné
2025-02-26 14:36 ` Jan Beulich
2025-02-26 16:04 ` Roger Pau Monné
2025-02-26 16:06 ` Jan Beulich
2025-02-26 16:34 ` Andrew Cooper
2025-02-26 16:42 ` Jan Beulich
2025-02-26 16:51 ` Andrew Cooper
2025-02-27 14:39 ` Alejandro Vallejo
2025-02-27 14:50 ` Alejandro Vallejo
2025-03-05 10:50 ` Jan Beulich
2025-02-26 14:02 ` Jan Beulich
2025-02-27 14:59 ` Alejandro Vallejo
2025-03-05 10:52 ` 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=D8DCAEVQKQFE.2W7VAZ1VZ9LZW@cloud.com \
--to=alejandro.vallejo@cloud.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=roger.pau@citrix.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.