Re: HVMlite ABI specification DRAFT A

["Roger Pau Monné" <roger.pau@citrix.com>]

El 4/2/16 a les 21:17, Boris Ostrovsky ha escrit:
> On 02/04/2016 02:21 PM, Roger Pau Monné wrote:
>> 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.
> 
> Then we should specify it somehow --- e.g. that first module is always
> the ramdisk.

No, that's how Linux uses it, but it's not part of the spec at all. From
a Xen PoV, this 'modules' are just memory regions, it doesn't know
anything else about them, neither it needs to.

>>> +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).
> 
> Doesn't this imply that strings should be part of this spec? Line "initrd"?

cmdline_paddr needs to be added to the spec, and I will do it in the
next revision (note that this will also require changes to the current
implementation). I'm not sure about your other part of the question,
making the concrete strings part of the implementation is completely out
of the spec, but I guess you mean something else which I don't get.

Roger.