Re: [Xen-devel] HVMlite ABI specification DRAFT A

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

El 4/2/16 a les 19:51, Samuel Thibault ha escrit:
> Boris Ostrovsky, on Thu 04 Feb 2016 13:38:02 -0500, wrote:
>> On 02/04/2016 12:48 PM, Roger Pau Monné wrote:
>>> The format of the boot start info structure is the following (pointed to
>>> be %ebx):
>>>
>>>     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 {
>>>         uint32_t paddr;             /* Physical address of the module.      
>>>      */
>>>         uint32_t size;              /* Size of the module in bytes.         
>>>      */
>>>     };
>>
>> If there is more than one module, how is the guest expected to sort out
>> which module is what?

In general I was expecting this would be done by position, or if that's
not enough an additional module (at either position 0 or n) should be
passed to contain that information.

> +1
> We need that to pass parameters to gnumach modules.

Hm, parameters as in a string that's paired with a module, or something
more complex like a metadata block?

I see that multiboot provides a string associated with each module, we
could do the same IMHO. I'm fine with adding it to the boot ABI, but I
would prefer if someone with access to such an OS does the actual
implementation of this feature.

Just to be clear that we are on the same page, then the _entry struct
becomes:

struct hvm_modlist_entry {
        uint32_t paddr;
        uint32_t size;
        uint32_t cmdline_paddr;
};

cmdline_paddr would work the same way as it does in the hvm_start_info
struct (ie: physical address of a zero-terminated ASCII string).

I think I'm going to re-write this in binary form (getting rid of the
structs), or else people are going to get the implementation wrong due
to paddings.

Roger.


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