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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/08/15 12:48, 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
>
> ---
> 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:

Perhaps note that this includes the example FreeBSD values.  It
shouldn't be implied that these are the exact notes which should be used.

>
> 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_PHYS32_ENTRY,          .quad,  xen_start32)

As this is strictly a 32bit entry, it can be .long rather than .quad

> ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,              .asciz, 
> "writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel")
> ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,    .long ((1 << 
> XENFEAT_writable_page_tables) | \
>                                                        (1 << 
> XENFEAT_auto_translated_physmap) | \
>                                                        (1 << 
> XENFEAT_supervisor_mode_kernel) | \
>                                                        (1 << 
> XENFEAT_hvm_callback_vector))

Can we see about fixing the overloading of XENFEAT_supervisor_mode_kernel ?

IMO it should be relegated to history.  It was an old,
not-fully-implemented pv feature (subsequently removed completely) which
is not relevant to HVM guests.

> <snip>
>
> Other relevant information needed in order to boot a guest kernel
> (console page address, xenstore event channel...) can be obtained
> using HVMPARAMS, just like it's done on HVM guests.
>
> The setup of the hypercall page is also performed in the same way
> as HVM guests, using a wrmsr.

using the hypervisor cpuid leaves and msr ranges.

~Andrew

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