Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932637AbdC1W4Q (ORCPT ); Tue, 28 Mar 2017 18:56:16 -0400 Received: from mail-vk0-f47.google.com ([209.85.213.47]:34683 "EHLO mail-vk0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932594AbdC1W4O (ORCPT ); Tue, 28 Mar 2017 18:56:14 -0400 MIME-Version: 1.0 In-Reply-To: <3cbfa24b-8bae-7cc9-dcf5-93f02971e673@zytor.com> References: <1490273467-97948-1-git-send-email-chao.p.peng@linux.intel.com> <20170323153117.GA6356@tigerII.localdomain> <1490333740.2925.7.camel@linux.intel.com> <20170327075817.bb7wda62fcuvfa4b@linutronix.de> <2e97b35f-bb9e-66e4-736d-66313626354e@suse.com> <1490702482.3011.7.camel@linux.intel.com> <3cbfa24b-8bae-7cc9-dcf5-93f02971e673@zytor.com> From: Andy Lutomirski Date: Tue, 28 Mar 2017 15:55:47 -0700 Message-ID: Subject: Re: [PATCH] x86/boot: Support uncompressed kernel To: "H. Peter Anvin" Cc: Chao Peng , Arnd Bergmann , Michal Marek , Sebastian Andrzej Siewior , Sergey Senozhatsky , Yinghai Lu , Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , Kees Cook , Baoquan He , "H.J. Lu" , Paul Bolle , Masahiro Yamada , Borislav Petkov , Andrew Morton , Petr Mladek , "David S. Miller" , "Paul E. McKenney" , Andy Lutomirski , Thomas Garnier , Nicolas Pitre , Tejun Heo , Daniel Mack , Helge Deller , Rik van Riel , Linux Kernel Mailing List , linux-kbuild Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1027 Lines: 22 On Tue, Mar 28, 2017 at 3:38 PM, H. Peter Anvin wrote: > On 03/28/17 05:01, Chao Peng wrote: >>> >>> I guess the next step would be to use CONFIG_XIP_KERNEL on x86, >>> which requires an uncompressed kernel but has the additional advantage >>> of sharing the read-only sections of the kernel image across virtual >>> machines, resulting in better RAM and cache usage. >> >> That is something we wanna look into :) >> > > It is, but that is a second order thing... especially since the x86 > kernel makes heavy use of self-patching at the moment. What would be > more significant, though, would be to avoid the memcpy() and instead > decode the uncompressed kernel in-place. > Having looked at this code recently, I'd rather fix it differently: use the streaming decompression API and integrate it with the ELF parsing code so we can decompress directly into the actual load location. Also, the parse_elf() code needs some serious improved documentation and robustification. It's absurdly fragile right now.