From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 3/5] libxc: create unmapped initrd in domain builder if supported Date: Fri, 11 Sep 2015 15:39:06 +0200 Message-ID: <55F2D97A.9070304@suse.com> References: <1441974742-27352-1-git-send-email-jgross@suse.com> <1441974742-27352-4-git-send-email-jgross@suse.com> <22002.52991.787690.357028@mariner.uk.xensource.com> <55F2D3D7.7010308@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55F2D3D7.7010308@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: Julien Grall , Ian Jackson Cc: xen-devel@lists.xensource.com, wei.liu2@citrix.com, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 09/11/2015 03:15 PM, Julien Grall wrote: > On 11/09/15 13:54, Ian Jackson wrote: >> Juergen Gross writes ("[PATCH 3/5] libxc: create unmapped initrd in domain builder if supported"): >>> In case the kernel of a new pv-domU indicates it is supporting an >>> unmapped initrd, don't waste precious virtual space for the initrd, >>> but allocate only guest physical memory for it. >> ... >> >> The name of this ELFNOTE suggests that it applies to all multiboot >> modules, not just ramdisks. In particular, that means perhaps it >> ought to apply to device tree blobs too ? > > The device tree blobs is not a multiboot module but directly pass in a > register to the kernel. > > FWIW, we don't have any ELF support right now on ARM. Okay, I thought so, but I wasn't sure. > >>> - /* load ramdisk */ >>> - if ( dom->ramdisk_blob ) >>> + /* Load ramdisk if initial mapping required. */ >>> + if ( dom->ramdisk_blob && >>> + (!dom->parms.elf_notes[XEN_ELFNOTE_MOD_START_PFN].data.num || >>> + dom->ramdisk_seg.vstart) ) >> >> After this patch the resulting structure of the code is rather >> unfortunate, in that the order of the main processing steps depends on >> this ELFNOTE. > > Shouldn't we ought to have a common code ELF agnostic? I.e we may have > other kernel image format where we have notes but not ELF notes. dom->parms is the same for all architectures. I think it would have to be extended in that case. Juergen