Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2123238ybv; Sun, 23 Feb 2020 23:15:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyjouM6uC68kQFFB7LK9tcGhjOtg8gr6s5QQSdTuaRkB2d/ppYeIIPDGbxlURT3kChgBOZL X-Received: by 2002:a05:6830:1e86:: with SMTP id n6mr39568271otr.321.1582528520623; Sun, 23 Feb 2020 23:15:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582528520; cv=none; d=google.com; s=arc-20160816; b=oNMlbDBp5c1Vp+4Ma8ClJFAmczu7x6d3mvTUlCG2KxOtsg0we0FWPkfiSiAUmx2Bam e10c9k8yqGiapC9eqg7KFNI0hW6d/vYR4D4ioGrfYjTvhMIr5GTmSF/w3Z1QdNREJJo/ a3hiRuipT7VMUZ483To26Hy4y5/kvUI2SBCdp38DsYesjlC4rSOyb2ghgqRDKJha0qRP Uq6xybTrnA09czus975bO8aejjtA/FZm0kE+R2x9tcZjcRK6jPfrTxSfnoMH88WnWizp 4+wuvFXWW1peyUc0GmQ2Kl7AIiZPlfezavJKGr1iBarVHVt4HVnXESqo8/YjrRuGM4c/ Id6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=shbhF5QPWUZF4FXtBT/Y7FxOTeIlf15w2VQZ89Q+vRY=; b=FaE08+qs8H3OePxM8Vb5XyhKIsjcf2cRLC6W4fMlpIK2tZeKHIL1fl3mXSiBKtxoP7 MY/Yy5Da3PIrgHIPeOKvTe4CfQ7n0+5rdUDWmcxgLw9ElV4lnQLlTHknU7j7fM/aIwMy xYsAgCFyNelZc4TtaRFcn3s8jjkgOlAWRjoGFPAd73uxb3fqAG4aB3TWP/woA8QAfPOw d+GlAB4QoG8UyHXANeF0E6H72uUS5qpuPYoyfARuNVIzuFB0E4WrFn6JQnoKaIPYl7SW q+3us7DbN/CRu2hR/maiVyoHu8E1Z5GEeRm6nnr5X1oHxeb9VBy5+MxjTY5oTf+d0Izh c5SA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UwKpSGkP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p186si4785834oih.172.2020.02.23.23.15.06; Sun, 23 Feb 2020 23:15:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UwKpSGkP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727115AbgBXHOb (ORCPT + 99 others); Mon, 24 Feb 2020 02:14:31 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:20298 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725792AbgBXHOb (ORCPT ); Mon, 24 Feb 2020 02:14:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582528470; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=shbhF5QPWUZF4FXtBT/Y7FxOTeIlf15w2VQZ89Q+vRY=; b=UwKpSGkPGh7UNxT74qJIn4FObT7Wn/jQ1aIzuxUWRXWRnUHq3XnFxTlfjQ4DabZcXo6bfY 2mU1CRKQiuKw5872w2bUqTEiOkfyserutaJ48qHePvl7vR5uQgptb1iqDGe5iWCZHv+rOB m6/v2bZIVfpsuaqi+1peTzwWhWoQhu4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-OTADVYNTP1KgIKmAqwLMEg-1; Mon, 24 Feb 2020 02:14:28 -0500 X-MC-Unique: OTADVYNTP1KgIKmAqwLMEg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DC3CE185734F; Mon, 24 Feb 2020 07:14:26 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-13-44.pek2.redhat.com [10.72.13.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 336B15C105; Mon, 24 Feb 2020 07:14:23 +0000 (UTC) Date: Mon, 24 Feb 2020 15:14:19 +0800 From: Dave Young To: Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: Re: [PATCH] x86/kexec: do not reserve kexec setup_data in kexec e820 table Message-ID: <20200224071419.GA18237@dhcp-128-65.nay.redhat.com> References: <20200212110424.GA2938@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212110424.GA2938@dhcp-128-65.nay.redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/20 at 07:04pm, Dave Young wrote: > The e820 table for kexec kernel always takes setup_data as reserved. > It is reasonable for the setup_data passed by the 1st kernel boot loader, > for example SETUP_PCI etc. But SETUP_EFI is used by kexec itself to > enable EFI in 2nd kernel, also kexec setups it every time. Thus it > is pointless to reserve kexec prepared setup_data. > > 1st physical boot: no SETUP_EFI > kexec load new kernel and prepare a SETUP_EFI setup_data, then reboot > -> 2nd kernel sees SETUP_EFI, reserves in both e820 and kexec e820 > another kexec load prepare a new SETUP_EFI, then reboot > -> 3rd kernel has two SETUP_EFI ranges reserved > -> and so on.. > > Thus skip SETUP_EFI while reserving setup_data for kexec kernel. > > Signed-off-by: Dave Young > --- > arch/x86/kernel/e820.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > --- linux-x86.orig/arch/x86/kernel/e820.c > +++ linux-x86/arch/x86/kernel/e820.c > @@ -999,7 +999,9 @@ void __init e820__reserve_setup_data(voi > while (pa_data) { > data = early_memremap(pa_data, sizeof(*data)); > e820__range_update(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN); > - e820__range_update_kexec(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN); > + /* Skip kexec passed setup_data */ > + if (data->type != SETUP_EFI) > + e820__range_update_kexec(pa_data, sizeof(*data)+data->len, E820_TYPE_RAM, E820_TYPE_RESERVED_KERN); > > if (data->type == SETUP_INDIRECT && > ((struct setup_indirect *)data->data)->type != SETUP_INDIRECT) { Ping, can someone review this? It caused fragmented memory in kexec kernel also waste memory. Thanks Dave