[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |