[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 24/44] x86/boot: remove module_map usage by ramdisk loading
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 <dpsmith@xxxxxxxxxxxxxxxxxxxx> --- 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |