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

Re: [Xen-devel] [PATCH] hvmlite: document the BSP/AP boot ABI



On Tue, 2015-12-15 at 18:27 +0100, Roger Pau Monne wrote:
> The discussion in [1] lead to an agreement of the missing pieces in PVH
> (or HVM without a device-model) in order to progress with it's
> implementation.
> 
> One of the missing pieces is a new boot ABI, that replaces the PV boot
> ABI. The aim of this new boot ABI is to remove the limitations of the
> PV boot ABI, that are no longer present when using auto-translated
> guests. The new boot protocol should allow to use the same entry point
> for both 32bit and 64bit guests, and let the guest choose it's bitness
> at run time without the domain builder knowing in advance.
> 
> This patch introduces a new document called hvmlite.markdown, with the
> intention of merging it into pvh.markdown once the HVMlite implementation
> has feature parity with PVH and the old PVH ABI is replaced with the
> HVMlite one.
> 
> [1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html
> 
> Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
> ---
> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Tim Deegan <tim@xxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> Âdocs/misc/hvmlite.markdown | 82
> ++++++++++++++++++++++++++++++++++++++++++++++
> Â1 file changed, 82 insertions(+)
> Âcreate mode 100644 docs/misc/hvmlite.markdown
> 
> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> new file mode 100644
> index 0000000..00ae423
> --- /dev/null
> +++ b/docs/misc/hvmlite.markdown
> @@ -0,0 +1,82 @@
> +**NOTE**: this document will be merged into `pvh.markdown` once PVH is
> replaced
> +with the HVMlite implementation.
> +
> +# HVM direct boot ABI #
> +
> +Since the Xen entry point into the kernel can be different from the
> +native entry point, a `ELFNOTE` is used in order to tell the domain
> +builder how to load and jump into the kernel entry point:
> +
> +ÂÂÂÂELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,ÂÂÂÂÂÂÂÂÂÂ.long,ÂÂxen_start32)
> +
> +The presence of the `XEN_ELFNOTE_PHYS32_ENTRY` note indicates that the
> +kernel supports the boot ABI described in this document.
> +
> +The domain builder will load the kernel into the guest memory space and
> +jump into the entry point defined at `XEN_ELFNOTE_PHYS32_ENTRY` with the
> +following machine state:
> +
> + * `ebx`: contains the physical memory address where the loader has
> placed
> +ÂÂÂthe boot start info structure.
> +
> + * `cr0`: bit 0 (PE) will be set. All the other writeable bits are
> cleared.
> +
> + * `cr4`: all bits are cleared.
> +
> + * `cs`: must be a 32-bit read/execute code segment with a base of â0â
> +ÂÂÂand a limit of â0xFFFFFFFFâ. The selector value is unspecified.
> +
> + * `ds`, `es`: must be a 32-bit read/write data segment with a base of
> +ÂÂÂâ0â and a limit of â0xFFFFFFFFâ. The selector values are all
> unspecified.
> +
> + * `tr`: must be a 32-bit TSS (active) with a base of '0' and a limit of
> '0x67'.
> +
> + * `eflags`: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared.
> +ÂÂÂBit 8 (TF) must be cleared. Other bits are all unspecified.

This list uses a mixture of "will be" and "must be", i.e. flips between
producer's and consumer's point of view.

I have no opinion on the technical content. Might be nice to prepend x86/
to the "HVM direct boot ABI" title, but meh.

Ian.

_______________________________________________
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®.