| Message ID | 20240830214730.1621-3-dpsmith@apertussolutions.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Boot modules for Hyperlaunch | expand |
On 30/08/2024 10:46 pm, Daniel P. Smith wrote: > Transition the incoming boot loader name to be held in struct boot_info. > > No functional change intended. > > Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> > --- > xen/arch/x86/include/asm/bootinfo.h | 2 ++ > xen/arch/x86/setup.c | 15 ++++++++------- > 2 files changed, 10 insertions(+), 7 deletions(-) > > diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h > index e850f80d26a7..e69feb1bb8be 100644 > --- a/xen/arch/x86/include/asm/bootinfo.h > +++ b/xen/arch/x86/include/asm/bootinfo.h > @@ -10,6 +10,8 @@ > > struct boot_info { > unsigned int nr_mods; > + > + const char *boot_loader_name; Simply loader, matching the __setup_xen() variable you dropped, will be fine. > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index dd94ee2e736b..432b7d1701e4 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -2054,7 +2055,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) > */ > dom0 = create_dom0(mod, modules_headroom, > initrdidx < boot_info->nr_mods ? mod + initrdidx : NULL, > - kextra, loader); > + kextra, boot_info->boot_loader_name); Do I want to know why create_dom0() cares about our bootloader? I'm sure the answer is no. ~Andrew
On 9/3/24 18:41, Andrew Cooper wrote: > On 30/08/2024 10:46 pm, Daniel P. Smith wrote: >> Transition the incoming boot loader name to be held in struct boot_info. >> >> No functional change intended. >> >> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> >> --- >> xen/arch/x86/include/asm/bootinfo.h | 2 ++ >> xen/arch/x86/setup.c | 15 ++++++++------- >> 2 files changed, 10 insertions(+), 7 deletions(-) >> >> diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h >> index e850f80d26a7..e69feb1bb8be 100644 >> --- a/xen/arch/x86/include/asm/bootinfo.h >> +++ b/xen/arch/x86/include/asm/bootinfo.h >> @@ -10,6 +10,8 @@ >> >> struct boot_info { >> unsigned int nr_mods; >> + >> + const char *boot_loader_name; > > Simply loader, matching the __setup_xen() variable you dropped, will be > fine. Yep, can do. >> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c >> index dd94ee2e736b..432b7d1701e4 100644 >> --- a/xen/arch/x86/setup.c >> +++ b/xen/arch/x86/setup.c >> @@ -2054,7 +2055,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) >> */ >> dom0 = create_dom0(mod, modules_headroom, >> initrdidx < boot_info->nr_mods ? mod + initrdidx : NULL, >> - kextra, loader); >> + kextra, boot_info->boot_loader_name); > > Do I want to know why create_dom0() cares about our bootloader? I'm > sure the answer is no. Because in cmdline_cook(), you have this: /* * PVH, our EFI loader, and GRUB2 don't include image name as first * item on command line. */ if ( xen_guest || efi_enabled(EFI_LOADER) || loader_is_grub2(loader_name) ) return p; Later in the series, all of this is no longer passed but it is still used by accessing the struct boot_info instance. v/r, dps
diff --git a/xen/arch/x86/include/asm/bootinfo.h b/xen/arch/x86/include/asm/bootinfo.h index e850f80d26a7..e69feb1bb8be 100644 --- a/xen/arch/x86/include/asm/bootinfo.h +++ b/xen/arch/x86/include/asm/bootinfo.h @@ -10,6 +10,8 @@ struct boot_info { unsigned int nr_mods; + + const char *boot_loader_name; }; #endif diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index dd94ee2e736b..432b7d1701e4 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -285,6 +285,9 @@ static void __init multiboot_to_bootinfo(multiboot_info_t *mbi) info.nr_mods = mbi->mods_count; + info.boot_loader_name = (mbi->flags & MBI_LOADERNAME) ? + __va(mbi->boot_loader_name) : "unknown"; + boot_info = &info; } @@ -993,7 +996,7 @@ static struct domain *__init create_dom0(const module_t *image, void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) { - const char *memmap_type = NULL, *loader, *cmdline = ""; + const char *memmap_type = NULL, *cmdline = ""; char *kextra; void *bsp_stack; struct cpu_info *info = get_cpu_info(), *bsp_info; @@ -1046,11 +1049,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) multiboot_to_bootinfo(mbi); - loader = (mbi->flags & MBI_LOADERNAME) ? __va(mbi->boot_loader_name) - : "unknown"; /* Parse the command-line options. */ if ( mbi->flags & MBI_CMDLINE ) - cmdline = cmdline_cook(__va(mbi->cmdline), loader); + cmdline = cmdline_cook(__va(mbi->cmdline), boot_info->boot_loader_name); if ( (kextra = strstr(cmdline, " -- ")) != NULL ) { @@ -1091,7 +1092,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) if ( pvh_boot ) pvh_print_info(); - printk("Bootloader: %s\n", loader); + printk("Bootloader: %s\n", boot_info->boot_loader_name); printk("Command line: %s\n", cmdline); @@ -1184,7 +1185,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) l3_bootmap[l3_table_offset(BOOTSTRAP_MAP_BASE)] = l3e_from_paddr(__pa(l2_bootmap), __PAGE_HYPERVISOR); - memmap_type = loader; + memmap_type = boot_info->boot_loader_name; } else if ( efi_enabled(EFI_BOOT) ) memmap_type = "EFI"; @@ -2054,7 +2055,7 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p) */ dom0 = create_dom0(mod, modules_headroom, initrdidx < boot_info->nr_mods ? mod + initrdidx : NULL, - kextra, loader); + kextra, boot_info->boot_loader_name); if ( !dom0 ) panic("Could not set up DOM0 guest OS\n");
Transition the incoming boot loader name to be held in struct boot_info. No functional change intended. Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> --- xen/arch/x86/include/asm/bootinfo.h | 2 ++ xen/arch/x86/setup.c | 15 ++++++++------- 2 files changed, 10 insertions(+), 7 deletions(-)