From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest Date: Mon, 25 Jan 2016 17:55:02 -0500 Message-ID: <56A6A7C6.8060906__33834.4850265004$1453762589$gmane$org@oracle.com> References: <1453498558-6028-1-git-send-email-boris.ostrovsky@oracle.com> <1453498558-6028-5-git-send-email-boris.ostrovsky@oracle.com> <20160122233218.GA20964@wotan.suse.de> <56A2C99A.2050701@citrix.com> <56A39300.8050802@citrix.com> <20160125221920.GG20964@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aNq2J-0007i5-A4 for xen-devel@lists.xenproject.org; Mon, 25 Jan 2016 22:55:03 +0000 In-Reply-To: <20160125221920.GG20964@wotan.suse.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" , Andrew Cooper Cc: Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , "linux-kernel@vger.kernel.org" , Andy Lutomirski , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Borislav Petkov , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= List-Id: xen-devel@lists.xenproject.org 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