From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: HVMlite ABI specification DRAFT A Date: Thu, 4 Feb 2016 15:17:21 -0500 Message-ID: <56B3B1D1.7070705@oracle.com> References: <56B38EDE.5090700@citrix.com> <56B39A8A.6090001@oracle.com> <20160204185125.GA3377@var.home> <56B3A4B4.20607@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aRQLD-0003eO-0c for xen-devel@lists.xenproject.org; Thu, 04 Feb 2016 20:17:23 +0000 In-Reply-To: <56B3A4B4.20607@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Samuel Thibault , xen-devel , Wei Liu , Andrew Cooper , Stefano Stabellini , Tim Deegan , Paul Durrant , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 02/04/2016 02:21 PM, Roger Pau Monn=E9 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=E9 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 0x336= ec578 */ >>>> /* ("xEn3" with the 0x80 bit of t= he "E" set).*/ >>>> uint32_t flags; /* SIF_xxx flags. = */ >>>> uint32_t cmdline_paddr; /* Physical address of the comman= d line. */ >>>> uint32_t nr_modules; /* Number of modules passed to th= e kernel. */ >>>> uint32_t modlist_paddr; /* Physical address of an array o= f */ >>>> /* 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. >