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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

>  * XEN_ELFNOTE_PADDR_ENTRY: the 32bit entry point into the kernel.
>  * XEN_ELFNOTE_FEATURES: features required by the guest kernel in order
>    to run.
> 
> The presence of the XEN_ELFNOTE_PADDR_ENTRY note indicates that the 
> kernel supports the boot ABI described in this document.
> 
> The domain builder will load the kernel into the guest memory space and 
> jump into the entry point defined at XEN_ELFNOTE_PADDR_ENTRY with the 
> following machine state:
> 
>  * esi: contains the physical memory address were the loader has placed
>    the start_info page.
> 
>  * eax: contains the magic value 0xFF6BC1E2.

On what basis was this value chosen? For my taste, it's getting too
close to something that could be a legitimate 32-bit kernel pointer
(agreed, all values could be valid pointers in 32-bit OSes, but with
OSes tending to place themselves high in memory, a value numerically
closer to what multiboot1 uses would seem more desirable).

>  * cr0: bit 31 (PG) must be cleared. Bit 0 (PE) must be set. Other bits
>    are all undefined. 

I see that grub1 documentation says so, but I doubt this is realistic
(even less so for cr4 bits): Some of the bits (including ones not
currently defined) may have a meaning even in non-paged protected
mode, and the environment should be as completely defined as possible.
I.e. I think most other bits should be defined to be zero upon handoff.

>  * cs: must be a 32-bit read/execute code segment with an offset of â0â
>    and a limit of â0xFFFFFFFFâ. The exact value is undefined.

I guess "exact value" really means "selector value".

>  * 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).

>  * eflags: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. 
>    Other bits are all undefined.
> 
>  * A20 gate: must be enabled.

This is irrelevant on other than physical machines.

> Comments for further discussion:
> 
> Do we want to keep using the start_info page? Most of the fields there 
> are not relevant for auto-translated guests, but without it we have to 
> figure out how to pass the following information to the guest:
> 
>  - Flags: SIF_xxx flags, this could probably be done with cpuid instead.
>  - cmd_line: ?
>  - console mfn: ?
>  - console evtchn: ?
>  - console_info address: ?

Yeah, settling on ideally a reasonably arch-independent mechanism
that doesn't place undue constraints on future ports would be nice.
And considering a hypothetical variant of x86 Xen not supporting PV
guests anymore, this would no longer define XEN_HAVE_PV_GUEST_ENTRY
and hence no longer have a struct start_info. So from a puristic pov
the information should indeed be conveyed another way.

Jan

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