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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

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