From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 2/2] xen/arm: support gzip compressed kernels Date: Thu, 3 Sep 2015 13:47:28 +0100 Message-ID: <55E84160.3040404@citrix.com> References: <1441193587-5209-2-git-send-email-stefano.stabellini@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1441193587-5209-2-git-send-email-stefano.stabellini@eu.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: Stefano Stabellini , xen-devel@lists.xensource.com Cc: ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 02/09/15 12:33, Stefano Stabellini wrote: > @@ -463,6 +520,15 @@ int kernel_probe(struct kernel_info *info) > printk("Loading ramdisk from boot module @ %"PRIpaddr"\n", > info->initrd_bootmodule->start); > > + if (!kernel_decompress(info, &start, &size)) Thinking a bit more about this check. It can fail either because the kernel is uncompressed or because we fail to decompress/allocate memory. I think we shouldn't continue if we are in the a latter. I know that we are continuing all the others caller but this is wrong and make the user confuse because it will see a message "Loading ELF image into guest" ... Doing the checking will also make obvious that we support uncompress kernel when reading the code. It's not straigh-forward while reading the patch. > + { > + /* Free the original kernel, update the pointers to the > + * decompressed kernel */ > + dt_unreserved_regions(mod->start, mod->start + mod->size, > + init_domheap_pages, 0); > + mod->start = start; > + mod->size = size; > + } > #ifdef CONFIG_ARM_64 > rc = kernel_zimage64_probe(info, start, size); > if (rc < 0) Regards, -- Julien Grall