Received: by 10.213.65.68 with SMTP id h4csp90917imn; Mon, 19 Mar 2018 20:50:37 -0700 (PDT) X-Google-Smtp-Source: AG47ELuH21QAnzZF4WPAsHLCwpbupZ6umfxvVcfcflzZOjL53Hep9pPZDMgWXPWaMiBJ656HKdku X-Received: by 2002:a17:902:9a42:: with SMTP id x2-v6mr2339255plv.201.1521517837539; Mon, 19 Mar 2018 20:50:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521517837; cv=none; d=google.com; s=arc-20160816; b=JBWQvJqWlzn7iXjo//yRwLoTswWJ6wUKjOhit3d1H7N8YWm8Y49aJgQDe7Kr3rnQFS Laa5xpWu2m0BMdM7ohKRiFMEsUtQ7Z9QgMncKGIB7jZYZZY/B/tqFmO206zd0FiY0Ttv Ose0AOhKKgcD6+MdyBzZ4YxQl3aagk4ME9Df44Ld+VVvicLUDhsmr2mVMNBmuY7eH6Av EGGxVru8t+RqnzXfe9y5nlwGIV31jT5Sz1DjEBBEek4Qrsj7oqIqRfWWijIL6lFmAXv7 aq8IME9iZ4PfDmgvOnaU6182ea6zHxoDP86sf7N5JCam+D9xp30JhJdrJqYyKs5ckcDI IuHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:to :from:date:arc-authentication-results; bh=xoNdW74aUrYMH06DL3bdPhmkbmsqiKgvFE33ZwNDXuo=; b=iSoI2BZ7AvHLpi9yFGJbvDgswku2VW+jhjXZYH47MNDJMe3P97Kyx8Y7NNsOnTSnDG JS3J8RgdnlYMCdtRO7ueEeA9Hg/unxAnk2UaaeNHDMUdxpfpIKSKn9MqY+haGa6O1aiI atUa6HFWogvTjatUDKnCLZ9yxYn5X83ds5lB2zU6wW9LfE8cfhOF60xLSJpIsG3Ne8br LQGi+7BW/lGDPwYEFc662qoJ8La6GEhRNSjIs7ACfCB5xE/PZmdiobnc4shN0ak6xmiU BxrbUQaYdJqO+eeQwjUo/1YB0LIKlT2wwy9Qm8fkkoT7mMr1FdfsGB3XF+RevnJOns+2 UXfA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 f89-v6si672593plb.687.2018.03.19.20.50.23; Mon, 19 Mar 2018 20:50:37 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751687AbeCTDsj (ORCPT + 99 others); Mon, 19 Mar 2018 23:48:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44988 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751581AbeCTDsh (ORCPT ); Mon, 19 Mar 2018 23:48:37 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A98E94023112; Tue, 20 Mar 2018 03:48:36 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D1B4100727A; Tue, 20 Mar 2018 03:48:33 +0000 (UTC) Date: Tue, 20 Mar 2018 11:48:28 +0800 From: Baoquan He To: AKASHI Takahiro , Dave Young , herbert@gondor.apana.org.au, ard.biesheuvel@linaro.org, catalin.marinas@arm.com, julien.thierry@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, dhowells@redhat.com, arnd@arndb.de, linux-arm-kernel@lists.infradead.org, mpe@ellerman.id.au, bauerman@linux.vnet.ibm.com, akpm@linux-foundation.org, Linus Torvalds , davem@davemloft.net, vgoyal@redhat.com Subject: Re: [PATCH v8 01/13] resource: add walk_system_ram_res_rev() Message-ID: <20180320034828.GB2514@localhost.localdomain> References: <20180222111732.23051-1-takahiro.akashi@linaro.org> <20180222111732.23051-2-takahiro.akashi@linaro.org> <20180223083619.GA4433@dhcp-128-65.nay.redhat.com> <20180320014318.GA2514@localhost.localdomain> <20180320031253.bwxat2dr3sns5uj4@dragonfly> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180320031253.bwxat2dr3sns5uj4@dragonfly> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 20 Mar 2018 03:48:36 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 20 Mar 2018 03:48:36 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/18 at 12:12pm, AKASHI Takahiro wrote: > Baoquan, > > On Tue, Mar 20, 2018 at 09:43:18AM +0800, Baoquan He wrote: > > On 02/23/18 at 04:36pm, Dave Young wrote: > > > Hi AKASHI, > > > > > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote: > > > > This function, being a variant of walk_system_ram_res() introduced in > > > > commit 8c86e70acead ("resource: provide new functions to walk through > > > > resources"), walks through a list of all the resources of System RAM > > > > in reversed order, i.e., from higher to lower. > > > > > > > > It will be used in kexec_file implementation on arm64. > > > > > > I remember there was an old discussion about this, it should be added > > > in patch log why this is needed. > > > > It's used to load kernel/initrd at the top of system RAM, and this is > > consistent with user space kexec behaviour. > > > > In x86 64, Vivek didn't do like this since there's no reverse iomem > > resource iterating function, he just chose a match RAM region bottom up, > > then put kernel/initrd top down in the found RAM region. This is > > different than kexec_tools utility. I am considering to change resource > > sibling as double list, seems AKASHI's way is easier to be accepted by > > people. So I will use this one to change x86 64 code. > > > > Hi AKASHI, > > > > About arm64 kexec_file patches, will you post recently? Or any other > > plan? > > A short answer is yes, but my new version won't include this specific patch. > So please feel free to add it to your own patch set if you want. > > The reason that I'm going to remove it is that we will make a modification > on /proc/iomem due to a bug fixing and then we will have to have our own > "walking" routine. I see. Saw your post about the /proc/iomem issue and discussions. Then I will add this patch in and post a patchset. Thanks Baoquan > > > > Thanks > > Baoquan > > > > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > Cc: Vivek Goyal > > > > Cc: Andrew Morton > > > > Cc: Linus Torvalds > > > > --- > > > > include/linux/ioport.h | 3 +++ > > > > kernel/resource.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > 2 files changed, 60 insertions(+) > > > > > > > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h > > > > index da0ebaec25f0..f12d95fe038b 100644 > > > > --- a/include/linux/ioport.h > > > > +++ b/include/linux/ioport.h > > > > @@ -277,6 +277,9 @@ extern int > > > > walk_system_ram_res(u64 start, u64 end, void *arg, > > > > int (*func)(struct resource *, void *)); > > > > extern int > > > > +walk_system_ram_res_rev(u64 start, u64 end, void *arg, > > > > + int (*func)(struct resource *, void *)); > > > > +extern int > > > > walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end, > > > > void *arg, int (*func)(struct resource *, void *)); > > > > > > > > diff --git a/kernel/resource.c b/kernel/resource.c > > > > index e270b5048988..bdaa93407f4c 100644 > > > > --- a/kernel/resource.c > > > > +++ b/kernel/resource.c > > > > @@ -23,6 +23,8 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > +#include > > > > #include > > > > > > > > > > > > @@ -486,6 +488,61 @@ int walk_mem_res(u64 start, u64 end, void *arg, > > > > arg, func); > > > > } > > > > > > > > +int walk_system_ram_res_rev(u64 start, u64 end, void *arg, > > > > + int (*func)(struct resource *, void *)) > > > > +{ > > > > + struct resource res, *rams; > > > > + int rams_size = 16, i; > > > > + int ret = -1; > > > > + > > > > + /* create a list */ > > > > + rams = vmalloc(sizeof(struct resource) * rams_size); > > > > + if (!rams) > > > > + return ret; > > > > + > > > > + res.start = start; > > > > + res.end = end; > > > > + res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > > > > + i = 0; > > > > + while ((res.start < res.end) && > > > > + (!find_next_iomem_res(&res, IORES_DESC_NONE, true))) { > > > > + if (i >= rams_size) { > > > > + /* re-alloc */ > > > > + struct resource *rams_new; > > > > + int rams_new_size; > > > > + > > > > + rams_new_size = rams_size + 16; > > > > + rams_new = vmalloc(sizeof(struct resource) > > > > + * rams_new_size); > > > > + if (!rams_new) > > > > + goto out; > > > > + > > > > + memcpy(rams_new, rams, > > > > + sizeof(struct resource) * rams_size); > > > > + vfree(rams); > > > > + rams = rams_new; > > > > + rams_size = rams_new_size; > > > > + } > > > > + > > > > + rams[i].start = res.start; > > > > + rams[i++].end = res.end; > > > > + > > > > + res.start = res.end + 1; > > > > + res.end = end; > > > > + } > > > > + > > > > + /* go reverse */ > > > > + for (i--; i >= 0; i--) { > > > > + ret = (*func)(&rams[i], arg); > > > > + if (ret) > > > > + break; > > > > + } > > > > + > > > > +out: > > > > + vfree(rams); > > > > + return ret; > > > > +} > > > > + > > > > #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY) > > > > > > > > /* > > > > -- > > > > 2.16.2 > > > > > > > > > > Thanks > > > Dave > > > > > > _______________________________________________ > > > kexec mailing list > > > kexec@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/kexec > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec