linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Dave Young <dyoung@redhat.com>,
	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 <torvalds@linux-foundation.org>,
	davem@davemloft.net, vgoyal@redhat.com
Subject: Re: [PATCH v8 01/13] resource: add walk_system_ram_res_rev()
Date: Tue, 20 Mar 2018 11:48:28 +0800	[thread overview]
Message-ID: <20180320034828.GB2514@localhost.localdomain> (raw)
In-Reply-To: <20180320031253.bwxat2dr3sns5uj4@dragonfly>

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 <takahiro.akashi@linaro.org>
> > > > Cc: Vivek Goyal <vgoyal@redhat.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > > > ---
> > > >  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 <linux/pfn.h>
> > > >  #include <linux/mm.h>
> > > >  #include <linux/resource_ext.h>
> > > > +#include <linux/string.h>
> > > > +#include <linux/vmalloc.h>
> > > >  #include <asm/io.h>
> > > >  
> > > >  
> > > > @@ -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

  reply	other threads:[~2018-03-20  3:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 11:17 [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 01/13] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2018-02-23  8:36   ` Dave Young
2018-03-20  1:43     ` Baoquan He
2018-03-20  3:12       ` AKASHI Takahiro
2018-03-20  3:48         ` Baoquan He [this message]
2018-02-22 11:17 ` [PATCH v8 02/13] kexec_file: make an use of purgatory optional AKASHI Takahiro
2018-02-23  8:49   ` Dave Young
2018-02-26 10:24     ` AKASHI Takahiro
2018-02-28 12:33       ` Dave Young
2018-03-01  2:59         ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 03/13] kexec_file,x86,powerpc: factor out kexec_file_ops functions AKASHI Takahiro
2018-02-23  9:24   ` Dave Young
2018-02-26 10:01     ` AKASHI Takahiro
2018-02-26 11:25       ` Philipp Rudo
2018-02-28 12:38       ` Dave Young
2018-03-01  3:18         ` AKASHI Takahiro
2018-02-26 11:17   ` [PATCH v8 03/13] kexec_file, x86, powerpc: " Philipp Rudo
2018-02-27  2:03     ` AKASHI Takahiro
2018-02-27  9:26       ` Philipp Rudo
2018-02-22 11:17 ` [PATCH v8 04/13] x86: kexec_file: factor out elf core header related functions AKASHI Takahiro
2018-02-24  3:15   ` Dave Young
2018-02-26  9:21     ` AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 05/13] kexec_file, x86: move re-factored code to generic side AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 06/13] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 07/13] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 08/13] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 09/13] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 10/13] arm64: kexec_file: add Image format support AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 11/13] arm64: kexec_file: enable KEXEC_FILE config AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 12/13] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-02-22 11:17 ` [PATCH v8 13/13] arm64: kexec_file: enable KEXEC_VERIFY_SIG for Image AKASHI Takahiro
2018-02-27  4:56 ` [PATCH v8 00/13] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-02-28 12:25   ` Dave Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180320034828.GB2514@localhost.localdomain \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=julien.thierry@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=takahiro.akashi@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).