From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
"Juergen Gross" <jgross@suse.com>,
"Jeremy Fitzhardinge" <jeremy@goop.org>,
"Rusty Russell" <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Andy Lutomirski" <luto@amacapital.net>,
"David Vrabel" <david.vrabel@citrix.com>,
"H. Peter Anvin" <hpa@zytor.com>,
xen-devel@lists.xenproject.org, "Borislav Petkov" <bp@suse.de>
Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest
Date: Mon, 25 Jan 2016 17:55:02 -0500 [thread overview]
Message-ID: <56A6A7C6.8060906@oracle.com> (raw)
In-Reply-To: <20160125221920.GG20964@wotan.suse.de>
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
next prev parent reply other threads:[~2016-01-25 22:55 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 21:35 [PATCH v1 00/12] HVMlite domU support Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 01/12] x86/smp: Make start_secondary() and initial_pg_pmd visible globally Boris Ostrovsky
2016-01-25 10:53 ` David Vrabel
2016-01-25 15:30 ` Boris Ostrovsky
2016-01-26 21:58 ` Borislav Petkov
2016-01-22 21:35 ` [PATCH v1 02/12] xen/hvmlite: Factor out common kernel init code Boris Ostrovsky
2016-01-22 23:01 ` Luis R. Rodriguez
2016-01-22 23:12 ` Boris Ostrovsky
2016-01-22 23:27 ` Boris Ostrovsky
2016-01-22 23:41 ` Luis R. Rodriguez
2016-01-25 11:04 ` [Xen-devel] " David Vrabel
2016-01-25 15:42 ` Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 03/12] xen/hvmlite: Import hvmlite-related Xen public interfaces Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest Boris Ostrovsky
2016-01-22 23:32 ` Luis R. Rodriguez
2016-01-23 0:30 ` [Xen-devel] " Andrew Cooper
2016-01-23 0:45 ` Luis R. Rodriguez
2016-01-23 0:55 ` Luis R. Rodriguez
2016-01-23 14:49 ` Andrew Cooper
2016-01-23 15:34 ` Konrad Rzeszutek Wilk
2016-01-23 16:01 ` H. Peter Anvin
2016-01-23 16:12 ` Konrad Rzeszutek Wilk
2016-01-23 18:28 ` H. Peter Anvin
2016-01-25 10:30 ` Roger Pau Monné
2016-01-25 22:19 ` Luis R. Rodriguez
2016-01-25 22:55 ` Boris Ostrovsky [this message]
2016-01-26 20:30 ` Luis R. Rodriguez
2016-01-26 21:51 ` Boris Ostrovsky
2016-01-27 0:04 ` Luis R. Rodriguez
2016-01-27 2:16 ` Luis R. Rodriguez
[not found] ` <CAB=NE6XRE42Y-WEkLbTXsvRg1+Fa4ZSi97wyPKiFT25o6=Y69w@mail.gmail.com>
[not found] ` <20160127144240.GB552@char.us.oracle.com>
2016-01-27 14:50 ` David Vrabel
2016-01-27 15:06 ` Boris Ostrovsky
2016-01-27 15:09 ` David Vrabel
2016-01-27 15:17 ` Boris Ostrovsky
[not found] ` <20160127152950.GH552@char.us.oracle.com>
2016-01-27 16:15 ` Boris Ostrovsky
2016-01-27 18:48 ` Luis R. Rodriguez
2016-01-27 19:00 ` Luis R. Rodriguez
2016-01-27 23:58 ` Boris Ostrovsky
2016-01-27 16:14 ` Borislav Petkov
2016-01-25 15:08 ` Boris Ostrovsky
2016-01-25 16:08 ` Boris Ostrovsky
2016-01-25 21:12 ` Luis R. Rodriguez
2016-01-25 21:21 ` H. Peter Anvin
2016-01-25 22:28 ` Boris Ostrovsky
2016-01-26 18:34 ` Luis R. Rodriguez
2016-01-26 18:46 ` Andy Lutomirski
2016-01-26 19:00 ` Boris Ostrovsky
2016-01-26 19:14 ` [Xen-devel] " Luis R. Rodriguez
2016-01-22 21:35 ` [PATCH v1 05/12] xen/hvmlite: Allow HVMlite guests delay initializing grant table Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 06/12] xen/hvmlite: Initialize PCI Boris Ostrovsky
2016-01-25 10:21 ` Roger Pau Monné
2016-01-22 21:35 ` [PATCH v1 07/12] xen/hvmlite: Prepare cpu_initialize_context() routine for HVMlite SMP Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 08/12] xen/hvmlite: Initialize context for secondary VCPUs Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 09/12] xen/hvmlite: Extend APIC operations for HVMlite guests Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 10/12] xen/hvmlite: Use x86's default timer init " Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 11/12] xen/hvmlite: Boot secondary CPUs Boris Ostrovsky
2016-01-22 21:35 ` [PATCH v1 12/12] xen/hvmlite: Enable CPU on-/offlining Boris Ostrovsky
2016-01-25 10:51 ` [PATCH v1 00/12] HVMlite domU support David Vrabel
2016-01-25 15:25 ` Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A6A7C6.8060906@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@suse.de \
--cc=david.vrabel@citrix.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mcgrof@suse.com \
--cc=roger.pau@citrix.com \
--cc=rusty@rustcorp.com.au \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).