Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/06/15 13:34, Roger Pau Monnà wrote:
> Hello,
>
> 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.
>
> Roger.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html

Fantastic - thanks for doing this.

>
> ---
> HVM direct boot ABI
>
> Since the Xen entry point into the kernel can be different from the 
> native entry point, ELFNOTES are used in order to tell the domain 
> builder how to load and jump into the kernel entry point. At least the 
> following ELFNOTES are required in order to use this boot ABI:
>
> ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,       .asciz, "FreeBSD")
> ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION,  .asciz, __XSTRING(__FreeBSD_version))
> ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION,    .asciz, "xen-3.0")
> ELFNOTE(Xen, XEN_ELFNOTE_PADDR_OFFSET,   .quad,  KERNBASE)
> ELFNOTE(Xen, XEN_ELFNOTE_PADDR_ENTRY,    .quad,  xen_start32)
> ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz, 
> "writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector")
> ELFNOTE(Xen, XEN_ELFNOTE_LOADER,         .asciz, "generic")
>
> The first three notes contain information about the guest kernel and 
> the Xen hypercall ABI version. The following notes are of special 
> interest:
>
>  * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
>    actual required physical address.
>  * XEN_ELFNOTE_PADDR_ENTRY: the 32bit entry point into the kernel.
>  * XEN_ELFNOTE_FEATURES: features required by the guest kernel in order
>    to run.
>
> The presence of the XEN_ELFNOTE_PADDR_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_PADDR_ENTRY with the 
> following machine state:
>
>  * esi: contains the physical memory address were the loader has placed
>    the start_info page.
>
>  * eax: contains the magic value 0xFF6BC1E2.
>
>  * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>    are all undefined. 

"unspecified" is perhaps better phrasing.  Most will be 0, but ET will
be set as it is a read-only bit in all processors Xen will function on
these days.

Perhaps also worth calling out cr4 as well, which typically starts as
all zeroes.

>
>  * cs: must be a 32-bit read/execute code segment with an offset of â0â
>    and a limit of â0xFFFFFFFFâ. The exact value is undefined.
>
>  * ds, es, fs, gs, ss: must be a 32-bit read/write data segment with an
>    offset of â0â and a limit of â0xFFFFFFFFâ. The exact values are all
>    undefined. 

I would be tempted to only define ds and possibly es.  Any code using
this boot protocol will load its gdt and reload the segments in very
short order, and ss is useless until esp has been set up appropriately.

>
>  * eflags: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. 
>    Other bits are all undefined.
>
>  * A20 gate: must be enabled.
>
> All other processor registers and flag bits are undefined. The OS is in 
> charge of setting up it's own stack, GDT and IDT.
>
> Note that the boot protocol resembles the multiboot1 specification, 
> this is done so OSes with multiboot1 entry points can reuse those if 
> desired. Also note that the processor starts with paging disabled, 
> which means that all the memory addresses in the start_info page will 
> be physical memory addresses.
>
> ---
> Comments for further discussion:
>
> Do we want to keep using the start_info page? Most of the fields there 
> are not relevant for auto-translated guests, but without it we have to 
> figure out how to pass the following information to the guest:
>
>  - Flags: SIF_xxx flags, this could probably be done with cpuid instead.
>  - cmd_line: ?
>  - console mfn: ?
>  - console evtchn: ?
>  - console_info address: ?

All console information should be available from the HVMPARAMS.  I see
no reason to prevent a PVH guest getting at these.

This just leaves the command line being awkward.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel