public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	andi@firstfloor.org, mingo@redhat.com, tglx@linutronix.de,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86 boot: add E820_RESVD_KERN
Date: Fri, 27 Jun 2008 11:03:04 +0800	[thread overview]
Message-ID: <1214535784.10865.14.camel@caritas-dev.intel.com> (raw)
In-Reply-To: <86802c440806261952u31de7262u37e1b4d628c9ffcf@mail.gmail.com>

On Thu, 2008-06-26 at 19:52 -0700, Yinghai Lu wrote:
> On Thu, Jun 26, 2008 at 7:48 PM, Huang, Ying <ying.huang@intel.com> wrote:
> > On Thu, 2008-06-26 at 19:22 -0700, Yinghai Lu wrote:
> >> On Thu, Jun 26, 2008 at 2:47 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >> > On Thu, Jun 26, 2008 at 12:48 AM, Huang, Ying <ying.huang@intel.com> wrote:
> >> >> On Thu, 2008-06-26 at 00:25 -0700, Yinghai Lu wrote:
> >> >> [...]
> >> >>> >                if (pfn >= limit_pfn)
> >> >>> > @@ -977,7 +978,7 @@ u64 __init early_reserve_e820(u64 startt
> >> >>> >                return 0;
> >> >>> >
> >> >>> >        addr = round_down(start + size - sizet, align);
> >> >>> > -       e820_update_range(addr, sizet, E820_RAM, E820_RESERVED);
> >> >>> > +       e820_update_range(addr, sizet, E820_RAM, E820_RESVD_KERN);
> >> >>>
> >> >>> this line is not needed.
> >> >>
> >> >> Why? Memory reserved by early_rserved_e820 should not be saved during
> >> >> hibernation? shoudl not be saved by kdump?
> >> >>
> >
> > Can you tell me why this line is not needed?
> 
> that function only have one user. the mpc reserve_new, so we want it
> to be E820_RESERVED, and kexec  tools could have that range reserved,
> the next kernel will not overwrite the updated mptable.

This is OK for kexec. Does it need to be saved by kdump? Does it need to
be saved by hibernation (suspend to disk)?

> >
> > [...]
> >> some like the attach patch...
> >>
> >> you still can merge parse_setup_data parse_e820_ext
> >> also entries in parse_e820_ext is not initialized..., __copy_e820_map
> >> will do nothing.
> >
> > OK. Because some E820 entries are available after parse_setup_data(),
> > it is better to call reserve_setup_data() after calling
> > parse_setup_data() if update_e820_range() is used instead of
> > reserve_early().
> 
> can you double check parse_e820_ext()?
> it seems entries is not initialized properly,
> 
> void __init parse_e820_ext(struct setup_data *sdata, unsigned long pa_data)
> {
>         u32 map_len;
>         int entries;
>         struct e820entry *extmap;
> 
>         entries = sdata->len / sizeof(struct e820entry);
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          here entries are initialized to be the number of entries in
          extended E820 table.
>         map_len = sdata->len + sizeof(struct setup_data);
>         if (map_len > PAGE_SIZE)
>                 sdata = early_ioremap(pa_data, map_len);
>         extmap = (struct e820entry *)(sdata->data);
>         __copy_e820_map(extmap, entries);===========> what is value for entries?
>         sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
>         if (map_len > PAGE_SIZE)
>                 early_iounmap(sdata, map_len);
>         printk(KERN_INFO "extended physical RAM map:\n");
>         e820_print_map("extended");
> }

Best Regards,
Huang Ying


  reply	other threads:[~2008-06-27  2:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26  6:32 [PATCH 1/2] x86 boot: add E820_RESVD_KERN Huang, Ying
2008-06-26  7:25 ` Yinghai Lu
2008-06-26  7:48   ` Huang, Ying
2008-06-26  9:47     ` Yinghai Lu
2008-06-27  2:22       ` Yinghai Lu
2008-06-27  2:48         ` Huang, Ying
2008-06-27  2:52           ` Yinghai Lu
2008-06-27  3:03             ` Huang, Ying [this message]
2008-06-27  5:36               ` Yinghai Lu
2008-06-27 22:05           ` Yinghai Lu
2008-06-30  7:03             ` Huang, Ying
2008-06-30  7:34               ` Yinghai Lu
2008-06-30  7:51                 ` Huang, Ying
2008-06-30  9:15                   ` Yinghai Lu
2008-06-30  9:31                     ` Yinghai Lu
2008-06-30  9:38                     ` Huang, Ying
2008-06-30 19:05                       ` Yinghai Lu
2008-06-30 19:16                         ` Ingo Molnar
2008-06-30 22:53                           ` Yinghai Lu
2008-06-30 23:20                             ` Yinghai Lu
2008-07-01  1:09                               ` Huang, Ying
2008-07-01  1:21                                 ` Yinghai Lu
2008-07-01  8:34                                   ` Ingo Molnar
2008-07-01  2:45                               ` Huang, Ying
2008-07-01  8:39                                 ` Ingo Molnar
2008-06-30  8:28             ` Ingo Molnar

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=1214535784.10865.14.camel@caritas-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=yhlu.kernel@gmail.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