[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft A] Boot ABI for HVM guests without a device-model
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. > 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. > 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. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |