Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Sat, Jan 23, 2016 at 02:49:36PM +0000, Andrew Cooper wrote:
> On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> > <andrew.cooper3@xxxxxxxxxx> wrote:
> >> the DMLite boot
> >> protocol is OS agnostic, and will be staying that way.
> > What's the DMLite boot protocol?
> 
> It is  a statement of the initial state of a DMLite container.

I see.

> > Is that the protocol that is defined by Xen to boot Xen guests and dom0?
> 
> Technically it is toolstack which constructs this initial state, but
> broadly yes.

I see thanks.

> >  Is this well documented somewhere?
> 
> There is a patch out on the list formalising the ABI in writing. (Roger:
> ping?)

Thanks for this.

> > To be clear are you saying that by no means will Xen change to instead
> > of setting a, say zero-page, it would just want to always stuff a xen
> > struct, pass that to the boot entry, and then expect always the guest
> > kernel to always parse this?
> 
> Correct.  Why do you think we should lumber non-Linux guests with a
> Linux-specific boot protocol?

You should by no means do that, agreed, however one should have the
flexibility to support such types of OSes that use page specific
settings for the OS. The way I see it this is an OS feature and
obviously it can vary.

> Quite apart from the fact that Linux is second to the table here
> (FreeBSD was first),

This means little but just history.

> it causes inappropriate linkage between the
> toolstack and the version of Linux wishing to be booted.

There are ways to do it in such a way that it does not create dependency issues
on Linux specific code.


0) The Xen way and EFI way

A generic data structure is passed to the entry point on the kernel to
load the kernel. The kernel in turn must parse this generic specific struct
and interprets it and translate it to the kernel specific values.

1) The qemu way:

One way is to simply not refer to the boot_params data structures but IMHO that
produces really ugly code. The qemu folks did it this way, so qemu does not use
arch/x86/include/uapi/asm/bootparam.h in any way, instead it uses offsets from
a char *header. Refer to load_linux() in hw/i386/pc.c, for instance:

header[0x211] |= 0x80;  /* CAN_USE_HEAP */

2) The grub way:

Another way, which grub uses, is to define their own data structures based
on arch/x86/include/uapi/asm/bootparam.h, with their own data types, and refer
to them in code, for instance refer to grub_cmd_linux() on the grub file
grub-core/loader/i386/pc/linux.c and its copy definition of the header 
definition
in include/grub/i386/linux.h.

lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;

The way lguest does it in the lguest launcher is IMHO the cleanest of course,
but it includes asm/bootparam.h and uses that in code:

/* Boot protocol version: 2.07 supports the fields for lguest. */       
boot->hdr.version = 0x207;  

But that does mean copying over or using the bootparam.h file and using
linux data types.

3) Merge of xen way and using subarch_data

Only set the subarch and subarch_data pointer, and have the kernel then
read the generic data structure and parse it as it used to, the benefit
is sharing a common entry point.

No one uses this yet. But I think its a reasonable compromise.

Perhaps there are other ways as well.

> > If true, then by no means, no matter how hard we try, and no matter
> > what we do on the Linux front to help clean things up will we be able
> > to have a unified bare metal / Xen entry. I'm noting it could be
> > possible though provided we do just set the zero page, the subarch to
> > Xen and subarch_data to the Xen custom data structure.
> 
> All you need is a very small stub which starts per the DMLite ABI, sets
> up an appropriate zero_page, and jumps to the native entrypoint.

Right.

> However, this stub belongs in Linux, not in the Xen toolstack.  That
> way, when the Linux boot protocol is modified, both sides can be updated
> accordingly.

Makes sense the different entry points just seems best avoided if possible.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel