The current usage of memblock_reserve() in init_pvh_bootparams() is done before
the .bss is zeroed, and that used to be fine when
memblock_reserved_init_regions implicitly ended up in the .meminit.data
section.  However after commit 73db3abdca58c memblock_reserved_init_regions
ends up in the .bss section, thus breaking it's usage before the .bss is
cleared.

Move and rename the call to xen_reserve_extra_memory() so it's done in the
x86_init.oem.arch_setup hook, which gets executed after the .bss has been
zeroed, but before calling e820__memory_setup().

Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
While the commit that introduced the user-noticeable regression is
73db3abdca58c, I think 38620fc4e893 should have been more careful to not
initialize the memblock ranges ahead of the .bss zeroing.
---
 arch/x86/include/asm/xen/hypervisor.h |  5 -----
 arch/x86/platform/pvh/enlighten.c     |  3 ---
 arch/x86/xen/enlighten_pvh.c          | 15 ++++++++++++---
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
index 64fbd2dbc5b7..a9088250770f 100644
--- a/arch/x86/include/asm/xen/hypervisor.h
+++ b/arch/x86/include/asm/xen/hypervisor.h
@@ -62,11 +62,6 @@ void xen_arch_unregister_cpu(int num);
 #ifdef CONFIG_PVH
 void __init xen_pvh_init(struct boot_params *boot_params);
 void __init mem_map_via_hcall(struct boot_params *boot_params_p);
-#ifdef CONFIG_XEN_PVH
-void __init xen_reserve_extra_memory(struct boot_params *bootp);
-#else
-static inline void xen_reserve_extra_memory(struct boot_params *bootp) { }
-#endif
 #endif
 
 /* Lazy mode for batching updates / context switch */
diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c
index 8c2d4b8de25d..944e0290f2c0 100644
--- a/arch/x86/platform/pvh/enlighten.c
+++ b/arch/x86/platform/pvh/enlighten.c
@@ -75,9 +75,6 @@ static void __init init_pvh_bootparams(bool xen_guest)
 	} else
 		xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
-	if (xen_guest)
-		xen_reserve_extra_memory(&pvh_bootparams);
-
 	pvh_bootparams.hdr.cmd_line_ptr =
 		pvh_start_info.cmdline_paddr;
 
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 91c6db4ec054..728a4366ca85 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -9,6 +9,7 @@
 #include <asm/io_apic.h>
 #include <asm/hypervisor.h>
 #include <asm/e820/api.h>
+#include <asm/setup.h>
 
 #include <xen/xen.h>
 #include <asm/xen/interface.h>
@@ -41,8 +42,9 @@ EXPORT_SYMBOL_GPL(xen_pvh);
  * hypervisor should notify us which memory ranges are suitable for creating
  * foreign mappings, but that's not yet implemented.
  */
-void __init xen_reserve_extra_memory(struct boot_params *bootp)
+static void __init pvh_reserve_extra_memory(void)
 {
+	struct boot_params *bootp = &boot_params;
 	unsigned int i, ram_pages = 0, extra_pages;
 
 	for (i = 0; i < bootp->e820_entries; i++) {
@@ -94,6 +96,14 @@ void __init xen_reserve_extra_memory(struct boot_params *bootp)
 	}
 }
 
+static void __init pvh_arch_setup(void)
+{
+	pvh_reserve_extra_memory();
+
+	if (xen_initial_domain())
+		xen_add_preferred_consoles();
+}
+
 void __init xen_pvh_init(struct boot_params *boot_params)
 {
 	u32 msr;
@@ -107,8 +117,7 @@ void __init xen_pvh_init(struct boot_params *boot_params)
 	pfn = __pa(hypercall_page);
 	wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 
-	if (xen_initial_domain())
-		x86_init.oem.arch_setup = xen_add_preferred_consoles;
+	x86_init.oem.arch_setup = pvh_arch_setup;
 	x86_init.oem.banner = xen_banner;
 
 	xen_efi_init(boot_params);
-- 
2.45.2

On 25.07.24 09:31, Roger Pau Monne wrote:
> The current usage of memblock_reserve() in init_pvh_bootparams() is done before
> the .bss is zeroed, and that used to be fine when
> memblock_reserved_init_regions implicitly ended up in the .meminit.data
> section.  However after commit 73db3abdca58c memblock_reserved_init_regions
> ends up in the .bss section, thus breaking it's usage before the .bss is
> cleared.
> 
> Move and rename the call to xen_reserve_extra_memory() so it's done in the
> x86_init.oem.arch_setup hook, which gets executed after the .bss has been
> zeroed, but before calling e820__memory_setup().
> 
> Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> While the commit that introduced the user-noticeable regression is
> 73db3abdca58c, I think 38620fc4e893 should have been more careful to not
> initialize the memblock ranges ahead of the .bss zeroing.

Reviewed-by: Juergen Gross <jgross@suse.com>

I'd prefer using 73db3abdca58c for the fixes tag. Otherwise you'd need to
add this patch to the stable branches, too, which is technically not really
needed.

Additionally I'd like to drop the Fixes: tag from the prereq patch, as this
one doesn't really fix anything.

I can do both while committing.


Juergen

On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
> On 25.07.24 09:31, Roger Pau Monne wrote:
> > The current usage of memblock_reserve() in init_pvh_bootparams() is done before
> > the .bss is zeroed, and that used to be fine when
> > memblock_reserved_init_regions implicitly ended up in the .meminit.data
> > section.  However after commit 73db3abdca58c memblock_reserved_init_regions
> > ends up in the .bss section, thus breaking it's usage before the .bss is
> > cleared.
> > 
> > Move and rename the call to xen_reserve_extra_memory() so it's done in the
> > x86_init.oem.arch_setup hook, which gets executed after the .bss has been
> > zeroed, but before calling e820__memory_setup().
> > 
> > Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > While the commit that introduced the user-noticeable regression is
> > 73db3abdca58c, I think 38620fc4e893 should have been more careful to not
> > initialize the memblock ranges ahead of the .bss zeroing.
> 
> Reviewed-by: Juergen Gross <jgross@suse.com>
> 
> I'd prefer using 73db3abdca58c for the fixes tag. Otherwise you'd need to
> add this patch to the stable branches, too, which is technically not really
> needed.
> 
> Additionally I'd like to drop the Fixes: tag from the prereq patch, as this
> one doesn't really fix anything.
> 
> I can do both while committing.

I was unsure myself (as noted in the post-commit notes) about which
"Fixes:" tag to use.

Is there anyway that it can be noted that this commit depends on the
previous change also being present?  For backport reasons, if anyone
ends up backporting 73db3abdca58c it would also need to pick the two
patches here.

Thanks, Roger.

On 25.07.24 10:10, Roger Pau Monné wrote:
> On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
>> On 25.07.24 09:31, Roger Pau Monne wrote:
>>> The current usage of memblock_reserve() in init_pvh_bootparams() is done before
>>> the .bss is zeroed, and that used to be fine when
>>> memblock_reserved_init_regions implicitly ended up in the .meminit.data
>>> section.  However after commit 73db3abdca58c memblock_reserved_init_regions
>>> ends up in the .bss section, thus breaking it's usage before the .bss is
>>> cleared.
>>>
>>> Move and rename the call to xen_reserve_extra_memory() so it's done in the
>>> x86_init.oem.arch_setup hook, which gets executed after the .bss has been
>>> zeroed, but before calling e820__memory_setup().
>>>
>>> Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
>>> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>>> ---
>>> While the commit that introduced the user-noticeable regression is
>>> 73db3abdca58c, I think 38620fc4e893 should have been more careful to not
>>> initialize the memblock ranges ahead of the .bss zeroing.
>>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>>
>> I'd prefer using 73db3abdca58c for the fixes tag. Otherwise you'd need to
>> add this patch to the stable branches, too, which is technically not really
>> needed.
>>
>> Additionally I'd like to drop the Fixes: tag from the prereq patch, as this
>> one doesn't really fix anything.
>>
>> I can do both while committing.
> 
> I was unsure myself (as noted in the post-commit notes) about which
> "Fixes:" tag to use.
> 
> Is there anyway that it can be noted that this commit depends on the
> previous change also being present?  For backport reasons, if anyone
> ends up backporting 73db3abdca58c it would also need to pick the two
> patches here.

This is normal business of backporting. This patch added to a stable kernel
would at least result in a build failure. The person doing the backport could
it either fixup locally in the backported patch, or look which patch did setup
the source to make this patch work.


Juergen