On 10/8/24 12:46, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
The ramdisk loading is the last user of module_map, remove
its usage and any remaining remnants of module_map.
Signed-off-by: Daniel P. Smith <[email protected]>
---
xen/arch/x86/setup.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b0946216ea3f..0d2ee19998aa 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1037,7 +1037,7 @@ void asmlinkage __init noreturn
__start_xen(unsigned long mbi_p)
struct boot_info *bi;
multiboot_info_t *mbi;
module_t *mod;
- unsigned long nr_pages, raw_max_page, module_map[1];
+ unsigned long nr_pages, raw_max_page;
int i, j, e820_warn = 0, bytes = 0;
unsigned long eb_start, eb_end;
bool acpi_boot_table_init_done = false, relocated = false;
@@ -1187,15 +1187,14 @@ void asmlinkage __init noreturn
__start_xen(unsigned long mbi_p)
panic("dom0 kernel not specified. Check bootloader
configuration\n");
/* Check that we don't have a silly number of modules. */
- if ( bi->nr_modules > sizeof(module_map) * 8 )
+ if ( bi->nr_modules > MAX_NR_BOOTMODS + 1 )
Don't you want to check MAX_NR_BOOTMODS, to keep the last module for Xen
itself?
Good question. I went back to confirm and it does not look like any of
the module_map bits was used for tracking xen in the module list. so
yes, drop it back down to just MAX_NR_BOOTMODS.
v/r,
dps
