The existing startup code employs various ad-hoc state tracking about certain
boot module types by each area of the code. A boot module flags bitfield is
added to enable tracking these different states. The first state to be
transition by this commit is module relocation.

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---
Changes since v6:
- replaced bitmask flags field with the bitfield, relocated
- slight update to commit message to mention bitfield
- dropped Rb and Ab due to approach change

Changes since v5:
- removed trailing blank line.
---
 xen/arch/x86/include/asm/bootinfo.h | 6 ++++++
 xen/arch/x86/setup.c                | 7 +++----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h
index 37dfcc14fa7d..0fbf36739782 100644
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -29,6 +29,12 @@ struct boot_module {
     module_t *mod;
 
     enum bootmod_type type;
+
+    /*
+     * Module State Flags:
+     *   relocated: indicates module has been relocated in memory.
+     */
+    bool relocated:1;
 };
 
 /*
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 92dbdfe12a3d..d061ece0541f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1392,7 +1392,6 @@ void asmlinkage __init noreturn __start_xen(void)
             panic("Bootloader didn't honor module alignment request\n");
         bi->mods[i].mod->mod_end -= bi->mods[i].mod->mod_start;
         bi->mods[i].mod->mod_start >>= PAGE_SHIFT;
-        bi->mods[i].mod->reserved = 0;
     }
 
     /*
@@ -1508,7 +1507,7 @@ void asmlinkage __init noreturn __start_xen(void)
             unsigned long headroom = j ? 0 : modules_headroom;
             unsigned long size = PAGE_ALIGN(headroom + bm->mod->mod_end);
 
-            if ( bm->mod->reserved )
+            if ( bm->relocated )
                 continue;
 
             /* Don't overlap with other modules (or Xen itself). */
@@ -1526,7 +1525,7 @@ void asmlinkage __init noreturn __start_xen(void)
                             pfn_to_paddr(bm->mod->mod_start), bm->mod->mod_end);
                 bm->mod->mod_start = (end - size) >> PAGE_SHIFT;
                 bm->mod->mod_end += headroom;
-                bm->mod->reserved = 1;
+                bm->relocated = true;
             }
         }
 
@@ -1552,7 +1551,7 @@ void asmlinkage __init noreturn __start_xen(void)
 #endif
     }
 
-    if ( modules_headroom && !bi->mods[0].mod->reserved )
+    if ( modules_headroom && !bi->mods[0].relocated )
         panic("Not enough memory to relocate the dom0 kernel image\n");
     for ( i = 0; i < bi->nr_modules; ++i )
     {
-- 
2.30.2

On 02/11/2024 5:25 pm, Daniel P. Smith wrote:
> The existing startup code employs various ad-hoc state tracking about certain
> boot module types by each area of the code. A boot module flags bitfield is
> added to enable tracking these different states. The first state to be
> transition by this commit is module relocation.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

This looks safe to rebase ahead of patch 2, making it able to be taken
without delay.  (With only a trivial adjustment vs bootmod_type in patch
1, it could probably go into staging without waiting for the rest of the
ucode-uaf fixes.)

On 11/6/24 09:38, Andrew Cooper wrote:
> On 02/11/2024 5:25 pm, Daniel P. Smith wrote:
>> The existing startup code employs various ad-hoc state tracking about certain
>> boot module types by each area of the code. A boot module flags bitfield is
>> added to enable tracking these different states. The first state to be
>> transition by this commit is module relocation.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> 
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> This looks safe to rebase ahead of patch 2, making it able to be taken
> without delay.  (With only a trivial adjustment vs bootmod_type in patch
> 1, it could probably go into staging without waiting for the rest of the
> ucode-uaf fixes.)

Thank you and I have no objections as it would reduce the size of v9.

v/r,
dps