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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/08/15 13:00, Jan Beulich wrote:
>
>> 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 was my fault for suggesting it like this, but on further
consideration, uint32_t's for both fields will be fine.  It won't be
interesting to load any modules outside of the 32bit boundary.

Anyone wishing to load more than 4GB of modules this way should go away
and rethink their boot procedure.

>
>> This structure is guaranteed to always be placed in memory after the
> DYM "These structures are ..."?
>
>> loaded kernel and modules.

There is no requirement for the command line/module information to be
after the loaded kernel.  All it needs to do is not overlap.

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

I agree it is unlikely to change (but there is a flags field just in
case), but we shouldn't impose unnecessary arbitrary restrictions.

~Andrew

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