diff mbox series

[v5,24/44] x86/boot: remove module_map usage by ramdisk loading

Message ID 20241006214956.24339-25-dpsmith@apertussolutions.com (mailing list archive)
State Superseded
Headers show
Series Boot modules for Hyperlaunch | expand

Commit Message

Daniel P. Smith Oct. 6, 2024, 9:49 p.m. UTC
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@apertussolutions.com>
---
 xen/arch/x86/setup.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Comments

Jason Andryuk Oct. 8, 2024, 4:46 p.m. UTC | #1
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@apertussolutions.com>
> ---
>   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?

Regards,
Jason

>       {
> -        bi->nr_modules = sizeof(module_map) * 8;
> -        printk("Excessive boot modules - using the first %u only\n",
> +        bi->nr_modules = MAX_NR_BOOTMODS + 1;
> +        printk("Excessive multiboot modules - using the first %u only\n",
>                  bi->nr_modules);
>       }
>   
> -    bitmap_fill(module_map, bi->nr_modules);
> -    __clear_bit(0, module_map); /* Dom0 kernel is always first */
> +    /* Dom0 kernel is always first */
>       bi->mods[0].type = BOOTMOD_KERNEL;
>       bi->mods[0].flags |= BOOTMOD_FLAG_X86_CONSUMED;
>
Daniel P. Smith Oct. 9, 2024, 6:36 p.m. UTC | #2
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@apertussolutions.com>
>> ---
>>   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
diff mbox series

Patch

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 )
     {
-        bi->nr_modules = sizeof(module_map) * 8;
-        printk("Excessive boot modules - using the first %u only\n",
+        bi->nr_modules = MAX_NR_BOOTMODS + 1;
+        printk("Excessive multiboot modules - using the first %u only\n",
                bi->nr_modules);
     }
 
-    bitmap_fill(module_map, bi->nr_modules);
-    __clear_bit(0, module_map); /* Dom0 kernel is always first */
+    /* Dom0 kernel is always first */
     bi->mods[0].type = BOOTMOD_KERNEL;
     bi->mods[0].flags |= BOOTMOD_FLAG_X86_CONSUMED;