From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [Draft B] Boot ABI for HVM guests without a device-model Date: Wed, 26 Aug 2015 13:12:40 +0100 Message-ID: <55DDAD38.9020200@citrix.com> References: <55DDA795.2010208@citrix.com> <55DDC684020000780009D1CC@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZUZZM-0000rD-If for xen-devel@lists.xenproject.org; Wed, 26 Aug 2015 12:12:44 +0000 In-Reply-To: <55DDC684020000780009D1CC@prv-mh.provo.novell.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: Jan Beulich , =?windows-1252?Q?Roger_Pau_Monn=E9?= Cc: Elena Ufimtseva , xen-devel , BorisOstrovsky , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 26/08/15 13:00, Jan Beulich wrote: > >> 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 { >> uint64_t paddr; /* Physical address of the module. */ >> uint64_t size; /* Size of the module in bytes. */ >> }; > Why is paddr 64-bit here, but 32-bit in both cases above? This was my fault for suggesting it like this, but on further consideration, uint32_t's for both fields will be fine. It won't be interesting to load any modules outside of the 32bit boundary. Anyone wishing to load more than 4GB of modules this way should go away and rethink their boot procedure. > >> This structure is guaranteed to always be placed in memory after the > DYM "These structures are ..."? > >> loaded kernel and modules. There is no requirement for the command line/module information to be after the loaded kernel. All it needs to do is not overlap. >> There's no upper bound on the size of the >> structure, users should be aware that it might cross a page boundary. > How is there no size limit? It's (currently) 16 bytes, and I don't see > why it would change. And even if - as implied by the previous > comment - this also relates to struct hvm_start_info: Its size is > fixed (and unlikely to change much) too. I agree it is unlikely to change (but there is a flags field just in case), but we shouldn't impose unnecessary arbitrary restrictions. ~Andrew