Re: New Xen boot infrastructure proposal

[Daniel Kiper <daniel.kiper@oracle.com>]

On Tue, May 21, 2013 at 01:03:48PM +0100, Jan Beulich wrote:
> >>> On 21.05.13 at 12:36, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > /* Xen Boot Info Arch (XBIA) memory map structure. */
> > typedef struct {
> >   /*
> >    * Amount of lower memory accordingly to The Multiboot
> >    * Specification version 0.6.96.
> >    */
> >   u32 lower;
> >   /*
> >    * Amount of upper memory accordingly to The Multiboot
> >    * Specification version 0.6.96.
> >    */
> >   u32 upper;
> >   u32 map_size;
> >   struct e820entry *e820map;
> > } xbia_mem_t;
>
> The concepts of lower, upper, and E820 memory are all very much
> tied to x86.

That is why this is a part of Xen Boot Info Arch (XBIA)
not Xen Boot Info (XBI) which is main struct.

> > /* Xen Boot Info Arch (XBIA). */
> > typedef struct {
> >   EFI_SYSTEM_TABLE *efi_system_table;
> >   u64 mps; /* Pointer to MPS. */
> >   u64 acpi; /* Pointer to ACPI RSDP. */
> >   u64 smbios; /* Pointer to SMBIOS. */
> >   xbia_mem_t mem;
> >   struct xen_vga_console_info vga_console_info;
> >   struct edd_info *edd_info;
> > } xbia_t;
>
> As are - I think - MPS, EDD, perhaps SMBIOS, and maybe VGA.

As above.

> If you want to design anything here (and other than you try to
> suggest I don't think booting is really a process that can be made
> almost arch neutral/generic), you'd need to completely separate

I am aware of that and I do not insist on doing it in that way.
I am just looking for best solution.

> out any _potentially_ arch specific things, not just those that
> today we know are specific to one arch or common between the
> only two and a half we support. That may mean that _each_ of

Right.

> the items above should become a separate one, in which case an
> enumeration concept would likely be the better one.

I do not fully understand what do you mean by "enumeration concept".

I think that passing info about system via many not "linked" variables
is not the best idea. It works in that way today because multiboot
structure is not extensible. That is why I think we should find new
solution. Our new custom build structure which contains only stuff
required by Xen looks good. All members are easliy accessible from C.
It could be easliy extended (if we need it just add new member) because
it would not be linked with specific boot protocol.

However, I agree that distinction between arch dependent and
independent stuff is disputable. Maybe we should drop that idea,
assume that Xen Boot Info (XBI) is always arch dependent and
put all needed members in one struct. IMO this is better solution
than current one too.

Daniel