From: "Jürgen Groß" <jgross@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Subject: Re: [PATCH] x86/xen: fix balloon target initialization for PVH dom0
Date: Wed, 2 Apr 2025 16:23:02 +0200 [thread overview]
Message-ID: <05974e77-ae3c-4e62-a2c2-c764ab4a6d48@suse.com> (raw)
In-Reply-To: <20250402113656.84673-1-roger.pau@citrix.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4680 bytes --]
On 02.04.25 13:36, Roger Pau Monne wrote:
> PVH dom0 re-uses logic from PV dom0, in which RAM ranges not assigned to
> dom0 are re-used as scratch memory to map foreign and grant pages. Such
> logic relies on reporting those unpopulated ranges as RAM to Linux, and
> mark them as reserved. This way Linux creates the underlying page
> structures required for metadata management.
>
> Such approach works fine on PV because the initial balloon target is
> calculated using specific Xen data, that doesn't take into account the
> memory type changes described above. However on HVM and PVH the initial
> balloon target is calculated using get_num_physpages(), and that function
> does take into account the unpopulated RAM regions used as scratch space
> for remote domain mappings.
>
> This leads to PVH dom0 having an incorrect initial balloon target, which
> causes malfunction (excessive memory freeing) of the balloon driver if the
> dom0 memory target is later adjusted from the toolstack.
>
> Fix this by using xen_released_pages to account for any pages that are part
> of the memory map, but are already unpopulated when the balloon driver is
> initialized. This accounts for any regions used for scratch remote
> mappings.
>
> Take the opportunity to unify PV with PVH/HVM guests regarding the usage of
> get_num_physpages(), as that avoids having to add different logic for PV vs
> PVH in both balloon_add_regions() and arch_xen_unpopulated_init().
>
> Much like a6aa4eb994ee, the code in this changeset should have been part of
> 38620fc4e893.
>
> Fixes: a6aa4eb994ee ('xen/x86: add extra pages to unpopulated-alloc if available')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> I think it's easier to unify the PV and PVH/HVM paths here regarding the
> usage of get_num_physpages(), as otherwise the fix needs to add further PV
> vs HVM divergences in both balloon_add_regions() and
> arch_xen_unpopulated_init(), but it also has a higher risk of breaking PV
> in subtle ways.
> ---
> arch/x86/xen/enlighten.c | 7 +++++++
> drivers/xen/balloon.c | 19 +++++++++++--------
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 43dcd8c7badc..651bb206434c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -466,6 +466,13 @@ int __init arch_xen_unpopulated_init(struct resource **res)
> xen_free_unpopulated_pages(1, &pg);
> }
>
> + /*
> + * Account for the region being in the physmap but unpopulated.
> + * The value in xen_released_pages is used by the balloon
> + * driver to know how much of the physmap is unpopulated and
> + * set an accurate initial memory target.
> + */
> + xen_released_pages += xen_extra_mem[i].n_pfns;
> /* Zero so region is not also added to the balloon driver. */
> xen_extra_mem[i].n_pfns = 0;
> }
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 163f7f1d70f1..085d418ee6da 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -698,7 +698,15 @@ static void __init balloon_add_regions(void)
> for (pfn = start_pfn; pfn < extra_pfn_end; pfn++)
> balloon_append(pfn_to_page(pfn));
>
> - balloon_stats.total_pages += extra_pfn_end - start_pfn;
> + /*
> + * Extra regions are accounted for in the physmap, but need
> + * decreasing from current_pages to balloon down the initial
> + * allocation, because they are already accounted for in
> + * total_pages.
> + */
> + BUG_ON(extra_pfn_end - start_pfn >=
> + balloon_stats.current_pages);
Maybe instead of crashing the system disable ballooning and print some
diagnostics why this happened?
> + balloon_stats.current_pages -= extra_pfn_end - start_pfn;
> }
> }
>
> @@ -711,13 +719,8 @@ static int __init balloon_init(void)
>
> pr_info("Initialising balloon driver\n");
>
> -#ifdef CONFIG_XEN_PV
> - balloon_stats.current_pages = xen_pv_domain()
> - ? min(xen_start_info->nr_pages - xen_released_pages, max_pfn)
> - : get_num_physpages();
> -#else
> - balloon_stats.current_pages = get_num_physpages();
> -#endif
> + BUG_ON(xen_released_pages >= get_num_physpages());
Again, I'd rather just disable ballooning instead of crashing the system.
> + balloon_stats.current_pages = get_num_physpages() - xen_released_pages;
> balloon_stats.target_pages = balloon_stats.current_pages;
> balloon_stats.balloon_low = 0;
> balloon_stats.balloon_high = 0;
Other than that I think your approach is fine.
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
prev parent reply other threads:[~2025-04-02 14:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 11:36 Roger Pau Monne
2025-04-02 14:23 ` Jürgen Groß [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=05974e77-ae3c-4e62-a2c2-c764ab4a6d48@suse.com \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®