[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:
On Sat, Jan 23, 2016 at 02:49:36PM +0000, Andrew Cooper wrote:


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.


I am trying to understand what your objection is to what is proposed in this patch. It is the size of the stub? If yes -- what would you like to leave out to be done later?


-boris


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.