[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.