[PATCH v2] x86/boot: Explain how discard_initial_images() works

Andrew Cooper posted 1 patch 3 weeks, 6 days ago
Failed in applying to current master (apply log)
xen/arch/x86/pv/dom0_build.c |  9 +++++++++
xen/arch/x86/setup.c         | 13 ++++++++++---
2 files changed, 19 insertions(+), 3 deletions(-)
[PATCH v2] x86/boot: Explain how discard_initial_images() works
Posted by Andrew Cooper 3 weeks, 6 days ago
discard_initial_images() only works because init_domheap_pages() with ps==pe
is a no-op.

In dom0_construct(), explaining the significance of setting the initrd length
to 0, and put an explicit check in discard_initial_images().

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Daniel Smith <dpsmith@apertussolutions.com>

v2:
 * Strip down to just the explanation, and merge into HL series.
---
 xen/arch/x86/pv/dom0_build.c |  9 +++++++++
 xen/arch/x86/setup.c         | 13 ++++++++++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index cdae17b27654..cc882bee61c3 100644
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -641,6 +641,15 @@ static int __init dom0_construct(struct domain *d,
                 if ( assign_pages(mfn_to_page(_mfn(mfn++)), 1, d, 0) )
                     BUG();
         }
+
+        /*
+         * We have either:
+         * - Mapped the initrd directly into dom0, or
+         * - Copied it and freed the module.
+         *
+         * Either way, tell discard_initial_images() to not free it a second
+         * time.
+         */
         initrd->mod_end = 0;
 
         iommu_memory_setup(d, "initrd", mfn_to_page(_mfn(initrd_mfn)),
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 511cf5b97909..177f4024abca 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -340,7 +340,7 @@ unsigned long __init initial_images_nrpages(nodeid_t node)
     return nr;
 }
 
-void __init discard_initial_images(void)
+void __init discard_initial_images(void) /* a.k.a. Free boot modules */
 {
     struct boot_info *bi = &xen_boot_info;
     unsigned int i;
@@ -348,9 +348,16 @@ void __init discard_initial_images(void)
     for ( i = 0; i < bi->nr_modules; ++i )
     {
         uint64_t start = pfn_to_paddr(bi->mods[i].mod->mod_start);
+        uint64_t size  = bi->mods[i].mod->mod_end;
 
-        init_domheap_pages(start,
-                           start + PAGE_ALIGN(bi->mods[i].mod->mod_end));
+        /*
+         * Sometimes the initrd is mapped, rather than copied, into dom0.
+         * Size being 0 is how we're instructed to leave the module alone.
+         */
+        if ( size == 0 )
+            continue;
+
+        init_domheap_pages(start, start + PAGE_ALIGN(size));
     }
 
     bi->nr_modules = 0;
-- 
2.39.5


Re: [PATCH v2] x86/boot: Explain how discard_initial_images() works
Posted by Jan Beulich 3 weeks, 2 days ago
On 24.10.2024 18:03, Andrew Cooper wrote:
> discard_initial_images() only works because init_domheap_pages() with ps==pe
> is a no-op.

And intentionally so. Hence why I don't mind ...

> In dom0_construct(), explaining the significance of setting the initrd length
> to 0, and put an explicit check in discard_initial_images().

... the extra conditional, I also don't really see why we would strictly need
it.

Jan
Re: [PATCH v2] x86/boot: Explain how discard_initial_images() works
Posted by Daniel P. Smith 3 weeks, 6 days ago
On 10/24/24 12:03, Andrew Cooper wrote:
> discard_initial_images() only works because init_domheap_pages() with ps==pe
> is a no-op.
> 
> In dom0_construct(), explaining the significance of setting the initrd length
> to 0, and put an explicit check in discard_initial_images().
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Daniel Smith <dpsmith@apertussolutions.com>

Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>