Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp390824ybt; Wed, 1 Jul 2020 00:42:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwoMUuV617OjJgMM6c73gtuMFCCutyQWeqSx0S5/RUxUl9fvcbArpZgDtNJcoJOKLFyqNJp X-Received: by 2002:a17:906:f20d:: with SMTP id gt13mr16333734ejb.117.1593589375670; Wed, 01 Jul 2020 00:42:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593589375; cv=none; d=google.com; s=arc-20160816; b=hniEd/Q3RAkF9t5R2td1xD07eSBl4FkK8sg17j+Bxq8DMIW/DKQ6V5ELqbYXieWObU 0RFk/CtpaY06sjbQZeIB4pmQ5Dqy8G6shWoZcMdwj1cCGniPtse1kQFdJ6GC+BunsCKH eeXT20oy/U/Dka53KYJ522DFTpb4plAQbAYpBNM/lC5TIfhM/2e3esG718g6AWGMi9u5 Rqq8tZm3ARembzwUIRg4/2OWYzSIV67sVCcQigcteNcwJwN1hSTqyVt0vSJGACGhM2FP 2EMhjc2O8DocDrdB59Pmn5LFm0ptZIYtVQBRbVqY7vlaijChlYeEfV2IQEOkMGuTqigj BSig== 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=izZP1MGTnUa71zOMjrTosKXYO8Y0RHaKMcIyCK6vJao=; b=ckaNc7+hPgrMF+kJanegx1XGnEw9ok/ZrZE9SuYD1/74sPecDVayJVU9eV36pd6rUd b5CeYfjOYkI0QjTPyBZbbL+/EWZUyRAjLBg5WV6EKcUy5L7xZGsyZ0MpPJ54m3j8UArc NnVlsSTmAX1TapSuhisG2e25RpZAuA+ZZrS49CmcavFSvykg+qrG7+tOOlLgk21hqBaV GrhHbNKeAEYI9Mf5o1A1JKrk3+qpNR5n7V83q5btEIIfyLXeCYrkJ82x5G011ewR1bcR nl8iaXg7G9N7TNMKdbKmAhdlpB0RV2nJY/6vuanAcyFNJvpRRBLBHlkUiwigsk3DNcL2 ibYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Xhrcp2PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id cf17si3354851edb.488.2020.07.01.00.42.32; Wed, 01 Jul 2020 00:42:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Xhrcp2PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728243AbgGAHk2 (ORCPT + 99 others); Wed, 1 Jul 2020 03:40:28 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:44779 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727836AbgGAHk0 (ORCPT ); Wed, 1 Jul 2020 03:40:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593589225; 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=izZP1MGTnUa71zOMjrTosKXYO8Y0RHaKMcIyCK6vJao=; b=Xhrcp2PXk3QzkokwRd3QcmIaftFPwO/YJi9DekMEzv+Mkxhe0GEqAuborXTAbp+71HxP6B FDvMURzahDw1jTcQrjvLPdQKQzrswl2OjbVXMs3PGTKzbSjPgEJMZPvkoF4TPK50AblijS Sj0PC6+eGQ7Y5RvJRIUPiLTnX/bm3DI= 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-381-MtDWQ3oVPeK49MAHXPiNSA-1; Wed, 01 Jul 2020 03:40:23 -0400 X-MC-Unique: MtDWQ3oVPeK49MAHXPiNSA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5F29A2CCC; Wed, 1 Jul 2020 07:40:21 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-207.pek2.redhat.com [10.72.12.207]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E639060FC2; Wed, 1 Jul 2020 07:40:15 +0000 (UTC) Date: Wed, 1 Jul 2020 15:40:12 +0800 From: Dave Young To: Hari Bathini Cc: Michael Ellerman , Andrew Morton , Pingfan Liu , Kexec-ml , Petr Tesarik , Mahesh J Salgaonkar , Sourabh Jain , lkml , linuxppc-dev , Mimi Zohar , Vivek Goyal , Thiago Jung Bauermann , Eric Biederman Subject: Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions Message-ID: <20200701074012.GA4496@dhcp-128-65.nay.redhat.com> References: <159319825403.16351.7253978047621755765.stgit@hbathini.in.ibm.com> <159319831192.16351.17443438699302756548.stgit@hbathini.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159319831192.16351.17443438699302756548.stgit@hbathini.in.ibm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hari, On 06/27/20 at 12:35am, Hari Bathini wrote: > crashkernel region could have an overlap with special memory regions > like opal, rtas, tce-table & such. These regions are referred to as > exclude memory ranges. Setup this ranges during image probe in order > to avoid them while finding the buffer for different kdump segments. > Implement kexec_locate_mem_hole_ppc64() that locates a memory hole > accounting for these ranges. Also, override arch_kexec_add_buffer() > to locate a memory hole & later call __kexec_add_buffer() function > with kbuf->mem set to skip the generic locate memory hole lookup. > > Signed-off-by: Hari Bathini > --- > arch/powerpc/include/asm/crashdump-ppc64.h | 10 + > arch/powerpc/include/asm/kexec.h | 7 - > arch/powerpc/kexec/elf_64.c | 7 + > arch/powerpc/kexec/file_load_64.c | 292 ++++++++++++++++++++++++++++ > 4 files changed, 312 insertions(+), 4 deletions(-) > create mode 100644 arch/powerpc/include/asm/crashdump-ppc64.h > [snip] > /** > + * get_exclude_memory_ranges - Get exclude memory ranges. This list includes > + * regions like opal/rtas, tce-table, initrd, > + * kernel, htab which should be avoided while > + * setting up kexec load segments. > + * @mem_ranges: Range list to add the memory ranges to. > + * > + * Returns 0 on success, negative errno on error. > + */ > +static int get_exclude_memory_ranges(struct crash_mem **mem_ranges) > +{ > + int ret; > + > + ret = add_tce_mem_ranges(mem_ranges); > + if (ret) > + goto out; > + > + ret = add_initrd_mem_range(mem_ranges); > + if (ret) > + goto out; > + > + ret = add_htab_mem_range(mem_ranges); > + if (ret) > + goto out; > + > + ret = add_kernel_mem_range(mem_ranges); > + if (ret) > + goto out; > + > + ret = add_rtas_mem_range(mem_ranges, false); > + if (ret) > + goto out; > + > + ret = add_opal_mem_range(mem_ranges, false); > + if (ret) > + goto out; > + > + ret = add_reserved_ranges(mem_ranges); > + if (ret) > + goto out; > + > + /* exclude memory ranges should be sorted for easy lookup */ > + sort_memory_ranges(*mem_ranges); > +out: > + if (ret) > + pr_err("Failed to setup exclude memory ranges\n"); > + return ret; > +} I'm confused about the "overlap with crashkernel memory", does that mean those normal kernel used memory could be put in crashkernel reserved memory range? If so why can't just skip those areas while crashkernel doing the reservation? Thanks Dave