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

[Tim Deegan <tim@xxxxxxx>]

At 14:15 +0100 on 10 Jun (1433945712), Jan Beulich wrote:
> >>> On 10.06.15 at 14:34, <roger.pau@xxxxxxxxxx> wrote:
> >  * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
> >    actual required physical address.
> 
> Why would that be needed? I.e. why would there ever be an offset?

I had the same question -- given that ELF provides physical load
addresses the obvious thing to do here is load at the specified
paddrs.

The example FreeBSD headers elsewhere in the thread just have paddr ==
vaddr, which is clearly not the case in a real machine, so we ought
to be able to use those fields for their intended purpose.

> >  * 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.
> 
> Same here, plus I don't think fs and gs should be defined to have any
> particular value, base, limit, or attributes (such that handing off with
> them holding nul selectors would become acceptable).

Given that this is just following the multiboot spec, and that once
you've set %ds, setting the others is effectively free, I think we
should set all of them.  

In fact, going further, I think we should just include the multiboot
spec by reference, and specify the changes that we will make, e.g.:

- different magic number, so the guest can tell what's going on
- allowing ELF64 binaries as well as ELF32
- how to get at boot info (i.e. cpuid -> hypercall table -> hvm params).

Cheers,

Tim.

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