Re: HVMlite ABI specification DRAFT A

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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.

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

-boris


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