|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/5] xen/x86: Migrate to boot_info structure
On 24/09/14 18:19, Daniel Kiper wrote:
> Break multiboot (v1) protocol dependency. It means that most of Xen code
> (excluding preloader) could be bootloader agnostic and does not need almost
> any knowledge about boot protocol. Additionally, we are able to pass all boot
> data to __start_xen() in one bucket without any side channels. I do not
> mention
> that we are also able to easily identify boot data in Xen code.
>
> Here is boot data flow for legacy BIOS platform:
>
> BIOS -> GRUB -> multiboot[12]* -> __reloc() -> MBD ->-\
> /
> ------<------<------<------<------<------<-----
> \
> \
> ---> __init_boot_info() -> boot_info_mb -> __start_xen() ->
> boot_info
> /
> BIOS ->-/
>
> * multiboot2 is not implemented yet. Look for it in later patches.
>
> Here is boot data flow for EFI platform:
>
> EFI -> efi_start() -> boot_info_efi -> __start_xen() -> boot_info
>
> WARNING: ARM build could be broken by this patch. We need to agree boot_info
> integration into ARM. Personally I think that it is worth storing all data
> from any bootloader and preloader in boot_info on any architecture. This give
> a chance to share more code between architectures. However, every architecture
> should define its own boot_info (in relevant include/asm directory). Despite
> that it looks that some parts of it could be common, e.g. modules data,
> command line arguments, boot loader name, EFI data, etc., even if types
> would not be the same. So, as it was stated above a lot of code could be
> shared among architectures.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
This patch is basically unreviewable. Please split it up more, starting
with misc cleanup such as video.h vs vga.h
e.g. start with
typedef struct {
/* Boot loader name. */
char *boot_loader_name;
} boot_info_t;
And make some stub declarations which set and retrieve the loader name
alone.
Then over the course of the following patches, move small bits one at a
time into this new structure, such as the command line then memory map,
acpi tables, smbios tables etc. This should probably be at least 8 patches.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |