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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.15 at 13:48, <roger.pau@xxxxxxxxxx> wrote:
>  * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of '0xFF'.

Why 0xFF instead of 0x67?

> struct hvm_start_info {
> #define HVM_START_MAGIC_VALUE 0x336ec578
>     uint32_t magic;             /* Contains the magic value 0x336ec578       
> */
>                                 /* ("xEn3" with the 0x80 bit of the "E" 
> set).*/
>     uint32_t flags;             /* SIF_xxx flags.                            
> */
>     uint32_t cmdline_paddr;     /* Physical address of the command line.     
> */
>     uint32_t nr_modules;        /* Number of modules passed to the kernel.   
> */
>     uint32_t modlist_paddr;     /* Physical address of an array of           
> */
>                                 /* hvm_modlist_entry.                        
> */
> };
> 
> struct hvm_modlist_entry {
>     uint64_t paddr;             /* Physical address of the module.           
> */
>     uint64_t size;              /* Size of the module in bytes.              
> */
> };

Why is paddr 64-bit here, but 32-bit in both cases above?

> This structure is guaranteed to always be placed in memory after the

DYM "These structures are ..."?

> loaded kernel and modules. There's no upper bound on the size of the
> structure, users should be aware that it might cross a page boundary.

How is there no size limit? It's (currently) 16 bytes, and I don't see
why it would change. And even if - as implied by the previous
comment - this also relates to struct hvm_start_info: Its size is
fixed (and unlikely to change much) too.

> Note that the boot protocol resembles the multiboot1 specification,
> this is done so OSes with multiboot1 entry points can reuse those if
> desired.

Which raises the question why we don't make it multiboot1 as much
as possible.

Jan


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