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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jun 11, 2015 at 10:43:08AM +0200, Roger Pau Monné wrote:
> El 10/06/15 a les 20.55, Konrad Rzeszutek Wilk ha escrit:
> > On Wed, Jun 10, 2015 at 02:34:00PM +0200, 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 
> > 
> > To be fair, there is an existing boot ABI.
> > 
> > It is the same as the PV boot but since it is an PV autotranslated
> > guest some of the values that an PV guest require are undefined.
> > 
> > With that in mind, why cannot we re-use that (xen_start_info) and
> > any field which is PV specific can be treated as reserved?
> 
> IMHO I would rather get rid of start_info and fetch everything using
> HVMPARAMS instead, this is more similar to what ARM guests already do.
> This means we can get rid of start_info in the long run, and that we
> don't paint ourselves into a corner, HVMPARAMS can always be expanded
> without problems.
> 
> >> 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.
> > 
> > I like that idea, but that will make the work going forward
> > on the 32-bit PVH and AMD PVH move out at least another half year
> > - which is rather sad.
> > 
> > Also this change will require modifying the Linux 64-bit PVH
> > part. That should be mentioned - and that is likely going to
> > take also three months.
> > 
> > 
> >>
> >> 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:
> >>
> >> 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")
> > 
> > That will choke on older hypervisors. That is a normal PV
> > guest won't boot anymore. That is because the older hypervisors
> > will choke on 'hvm_callback_vector' being in the XEN_ELFNOTE_FEATURES.
> 
> I see, this is what FreeBSD currently uses. We are going to choke on
> older hypervisors anyway, since FreeBSD only supports PVH.

Linux would choke too. I would like Linux (next-version) to still
work on Amazon installations that use older hypervisor.

> 
> > You have to stick that in XEN_ELFNOTE_SUPPORTED_FEATURES field.
> > 
> >> 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.
> > 
> > Is 'P' suppose to be 'physical' ?
> > 
> > I am not sure how this will work with an ELF 64-bit binary like
> > the Linux kernel. Usually we use the virtual address but with
> > us starting in 32-bit mode with an 64-bit virtual address won't work.
> 
> That's why we are defining a new entry point instead of reusing the
> current XEN_ELFNOTE_ENTRY note. This entry point is expected to be a
> 32bit physical address.

Thanks, Jan clued me in.
> 
> > But the ELF loader could figure out the offset of the virtual
> > address from the ELF starting point and just call at the delta - in
> > which case having XEN_ELFNOTE_ENTRY can be used with the
> > understanding that we will just call at that that offset.
> 
> I'm not following you here, I don't think it's possible to reuse the
> same entry point, that's why this new ELFNOTE is proposed.

<nods>
> 
> Roger.
> 

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