Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Masayoshi Mizuma <msys.mizuma@gmail.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: kexec mailing list <kexec@lists.infradead.org>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	Simon Horman <horms@verge.net.au>,
	James Morse <james.morse@arm.com>
Subject: Re: [PATCH v2 2/3] arm64: kexec: allocate memory space avoiding reserved regions
Date: Wed, 18 Dec 2019 10:08:48 -0500	[thread overview]
Message-ID: <20191218150848.anisllbuawkwolm6@gabell> (raw)
In-Reply-To: <20191218024849.GA7386@linaro.org>

On Wed, Dec 18, 2019 at 11:48:50AM +0900, AKASHI Takahiro wrote:
> On Mon, Dec 16, 2019 at 09:16:06AM -0500, Masayoshi Mizuma wrote:
> > On Mon, Dec 16, 2019 at 11:22:56AM +0530, Bhupesh Sharma wrote:
> > > Thanks Masa,
> 
> [...]
> 
> > > Since this is an old thread, it would be useful for people looking at
> > > the same, if you can add some comments/details about why you think
> > > this nit is needed.
> > 
> > Thank you for your follow up and I'm sorry I didn't explain it.
> > mem_regions_alloc_and_exclude() may fail in case realloc() or
> > mem_region_exclude() fail, so it would be better to add the error
> > handling.
> > 
> > > 
> > > Also if Akashi agrees with the same, it would be better if he could
> > > send a rebased version of the patchset (with your comments addressed),
> > > so that the same can be picked for upstream kexec-tools cleanly.
> > 
> > Sounds great!
> 
> I have almost forgotten the background of this patch.
> If you see that it is still useful, please feel free to re-post it.

Thanks! I'll repost the patchset as v3.

- Masa
> 
> Thanks,
> -Takahiro Akashi
> 
> > - Masa
> > 
> > > 
> > > @Akashi- Hi Akashi, Please let us know your views.
> > > 
> > > Thanks,
> > > Bhupesh
> > > 
> > > > +                     dbgprintf("%s:-      %016llx - %016llx\n",
> > > > > +                                     __func__, start, end);
> > > > > +             }
> > > > > +     }
> > > > > +
> > > > > +     fclose(fp);
> > > > > +
> > > > > +     *range = memranges.ranges;
> > > > > +     *ranges = memranges.size;
> > > > >
> > > > >       /* As a fallback option, we can try determining the PHYS_OFFSET
> > > > >        * value from the '/proc/iomem' entries as well.
> > > > > @@ -976,52 +1041,15 @@ static int get_memory_ranges_iomem_cb(void *data, int nr, char *str,
> > > > >        * between the user-space and kernel space 'PHYS_OFFSET'
> > > > >        * value.
> > > > >        */
> > > > > -     set_phys_offset(r->start, "iomem");
> > > > > +     if (memranges.size)
> > > > > +             set_phys_offset(memranges.ranges[0].start, "iomem");
> > > > >
> > > > > -     dbgprintf("%s: %016llx - %016llx : %s", __func__, r->start,
> > > > > -             r->end, str);
> > > > > +     dbgprint_mem_range("System RAM ranges;",
> > > > > +                             memranges.ranges, memranges.size);
> > > > >
> > > > >       return 0;
> > > > >  }
> > > > >
> > > > > -/**
> > > > > - * get_memory_ranges_iomem - Try to get the memory ranges from
> > > > > - * /proc/iomem.
> > > > > - */
> > > > > -
> > > > > -static int get_memory_ranges_iomem(struct memory_range *array,
> > > > > -     unsigned int *count)
> > > > > -{
> > > > > -     *count = kexec_iomem_for_each_line(NULL,
> > > > > -             get_memory_ranges_iomem_cb, array);
> > > > > -
> > > > > -     if (!*count) {
> > > > > -             dbgprintf("%s: failed: No RAM found.\n", __func__);
> > > > > -             return EFAILED;
> > > > > -     }
> > > > > -
> > > > > -     return 0;
> > > > > -}
> > > > > -
> > > > > -/**
> > > > > - * get_memory_ranges - Try to get the memory ranges some how.
> > > > > - */
> > > > > -
> > > > > -int get_memory_ranges(struct memory_range **range, int *ranges,
> > > > > -     unsigned long kexec_flags)
> > > > > -{
> > > > > -     static struct memory_range array[KEXEC_SEGMENT_MAX];
> > > > > -     unsigned int count;
> > > > > -     int result;
> > > > > -
> > > > > -     result = get_memory_ranges_iomem(array, &count);
> > > > > -
> > > > > -     *range = result ? NULL : array;
> > > > > -     *ranges = result ? 0 : count;
> > > > > -
> > > > > -     return result;
> > > > > -}
> > > > > -
> > > > >  int arch_compat_trampoline(struct kexec_info *info)
> > > > >  {
> > > > >       return 0;
> > > > > --
> > > > > 2.19.1
> > > > >
> > > > >
> > > >
> > > 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2019-12-18 15:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11  9:59 [PATCH v2 0/3] arm64: handle "reserved" entries in /proc/iomem AKASHI Takahiro
2019-01-11  9:59 ` [PATCH v2 1/3] kexec: add variant helper functions for handling memory regions AKASHI Takahiro
2019-01-11  9:59 ` [PATCH v2 2/3] arm64: kexec: allocate memory space avoiding reserved regions AKASHI Takahiro
2019-12-13 20:04   ` Masayoshi Mizuma
2019-12-16  5:52     ` Bhupesh Sharma
2019-12-16 14:16       ` Masayoshi Mizuma
2019-12-18  2:48         ` AKASHI Takahiro
2019-12-18 15:08           ` Masayoshi Mizuma [this message]
2019-01-11  9:59 ` [PATCH v2 3/3] arm64: kdump: deal with a lot of resource entries in /proc/iomem AKASHI Takahiro
2019-01-13 11:36 ` [PATCH v2 0/3] arm64: handle "reserved" " Bhupesh Sharma
2019-12-13 19:53 ` Masayoshi Mizuma

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=20191218150848.anisllbuawkwolm6@gabell \
    --to=msys.mizuma@gmail.com \
    --cc=bhsharma@redhat.com \
    --cc=horms@verge.net.au \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=takahiro.akashi@linaro.org \
    /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