On 04/11/14 at 11:00am, WANG Chao wrote:
> On 04/11/14 at 10:47am, 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.
> >
> > 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. range[].end is inclusive and size should be (end - start + 1)
In kexec path, memory range .end is exclusive however. I think it should
also be updated to inclusive to unify the encoding of memory range for
both kexec and kdump.
