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@lists.xen.org
http://lists.xen.org/xen-devel
