From: "H. Peter Anvin" <hpa@zytor.com>
To: Dave Young <dyoung@redhat.com>
Cc: kexec@lists.infradead.org, WANG Chao <chaowang@redhat.com>,
horms@verge.net.au, linn@hp.com, trenn@suse.de,
vgoyal@redhat.com, ebiederm@xmission.com
Subject: Re: [PATCH v5 09/10] x86: Pass memory range via E820 for kdump
Date: Thu, 10 Apr 2014 19:55:27 -0700 [thread overview]
Message-ID: <5347599F.8040703@zytor.com> (raw)
In-Reply-To: <20140411024730.GH5493@dhcp-16-198.nay.redhat.com>
On 04/10/2014 07:47 PM, Dave Young wrote:
> On 04/10/14 at 07:36pm, H. Peter Anvin wrote:
>> On 04/10/2014 07:28 PM, Dave Young wrote:
>>>>
>>>> +static void add_e820_map_from_mr(struct x86_linux_param_header *real_mode,
>>>> + struct e820entry *e820, struct memory_range *range, int nr_range)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < nr_range; i++) {
>>>> + e820[i].addr = range[i].start;
>>>> + e820[i].size = range[i].end - range[i].start;
>>>
>>> I see it's same as original code but I still feel it should be end - start + 1;
>>>
>>
>> I can't see how it could possibly be +1.
>>
>> How do you encode range[].end? If it is inclusive it should be end -
>> start - 1, if it is a semiclosed range (the normal thing in computer
>> contexts) then the code above is correct.
I obviously got the above backwards in my head. Please ignore.
>
> Say the first range from my /proc/iomem:
> 00000000-00000fff : reserved
>
> Shouldn't the size be 0x1000? It looks like closed range instead of semiclosed range.
You're right. I thought we mangled the contents for /proc/iomem, but we
actually keep the contents as a closed range.
So never mind me! -ENOBRAINTODAY.
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-04-11 2:56 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 9:12 [PATCH v5 00/10] kexec-tools, x86: E820 memmap pass for kdump WANG Chao
2014-04-10 9:12 ` [PATCH v5 01/10] x86, cleanup: fix indent WANG Chao
2014-04-10 9:12 ` [PATCH v5 02/10] x86, cleanup: add extra arguments to add_memmap() and delete_memmap() WANG Chao
2014-04-11 2:22 ` Dave Young
2014-04-11 4:47 ` WANG Chao
2014-04-10 9:12 ` [PATCH v5 03/10] x86, cleanup: add other types of memory range for 2nd kernel boot to memmap_p WANG Chao
2014-04-11 2:24 ` Dave Young
2014-04-11 3:02 ` WANG Chao
2014-04-10 9:12 ` [PATCH v5 04/10] x86, cleanup: add_memmap() only do alignment check on RANGE_RAM WANG Chao
2014-04-10 9:12 ` [PATCH v5 05/10] x86, cleanup: use dbgprint_mem_range for memory range debugging WANG Chao
2014-04-10 20:18 ` Linn Crosetto
2014-04-11 2:00 ` Dave Young
2014-04-11 2:11 ` WANG Chao
2014-04-10 9:12 ` [PATCH v5 06/10] x86, cleanup: increase CRASH_MAX_MEMMAP_NR up to CRASH_MAX_MEMORY_RANGES WANG Chao
2014-04-10 9:13 ` [PATCH v5 06/10] x86, cleanup: Store crash memory ranges kexec_info WANG Chao
2014-04-11 2:20 ` Dave Young
2014-04-11 3:17 ` WANG Chao
2014-04-11 6:10 ` Dave Young
2014-04-11 6:50 ` WANG Chao
2014-04-11 7:02 ` Dave Young
2014-04-10 9:13 ` [PATCH v5 07/10] x86, cleanup: Add a funtion add_setup_data() WANG Chao
2014-04-10 9:13 ` [PATCH v5 07/10] x86, cleanup: Store crash memory ranges kexec_info WANG Chao
2014-04-10 9:13 ` [PATCH v5 08/10] x86: add --pass-memmap-cmdline option WANG Chao
2014-04-10 9:13 ` [PATCH v5 08/10] x86, cleanup: Add a funtion add_setup_data() WANG Chao
2014-04-10 9:13 ` [PATCH v5 09/10] x86: add --pass-memmap-cmdline option WANG Chao
2014-04-10 9:13 ` [PATCH v5 09/10] x86: Pass memory range via E820 for kdump WANG Chao
2014-04-11 2:28 ` Dave Young
2014-04-11 2:36 ` H. Peter Anvin
2014-04-11 2:47 ` Dave Young
2014-04-11 2:55 ` H. Peter Anvin [this message]
2014-04-11 3:00 ` WANG Chao
2014-04-11 3:33 ` WANG Chao
2014-04-11 2:06 ` [PATCH v5 00/10] kexec-tools, x86: E820 memmap pass " Dave Young
2014-04-11 2:14 ` WANG Chao
2014-04-11 3:05 ` WANG Chao
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=5347599F.8040703@zytor.com \
--to=hpa@zytor.com \
--cc=chaowang@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linn@hp.com \
--cc=trenn@suse.de \
--cc=vgoyal@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.