[PATCH 2/2] makedumpfile: Use max_pfn from mem_map array

[Atsushi Kumagai]

[...]
>>
>> In the first place, we shouldn't truncate max_mapnr
>> based on dom0's mem_section since there are some domU's
>> memories on Xen dumps. Now, I think a better way for Xen
>> is just leaving max_mapnr as it is.
>>
>> Do you agree with my view ?
>
>Definitely! For Xen, info->max_mapnr gives the maximum machine PFN
>(ie. it corresponds to total memory installed in the machine).
>
>The data in mem_section describes Dom0 kernel memory map (and gets
>initialized from info->dom0_mapnr). It may be substantially smaller
>than info->max_mapnr...

Thanks for your confirming.

>A "clean" solution would be to change info->max_mapnr so that it always
>gives the maximum physical PFN, but that doesn't fly very well in
>practice, because memory bitmaps and other stuff must still be sized
>according to the number of machine PFNs, so I would have to add special
>cases all around the place...

I don't know how to capture a dump on Xen well, so do you have any idea
how to produce the difference between actual memory regions and the ELF
header like the s390 case ?
If it isn't possible, we don't need to change info->max_mapnr since the
value calculated from the ELF header must be correct.

>OTOH, Michal's patch is still neded to fix non-Xen non-cyclic dumps.

Yes, the fix for create_1st_bitmap() is still necessary.

Michael, could you fix your patch ? We need to add the conditional
check for Xen like below:

+	if (!is_xen_memory()) {
+	       for (i = 0; i < info->num_mem_map; i++) {
+   	            if (info->mem_map_data[i].mem_map == NOT_MEMMAP_ADDR)
+       	                continue;
+           	    max_pfn = MAX(max_pfn, info->mem_map_data[i].pfn_end);
+       	}
+       	info->max_mapnr = MIN(info->max_mapnr, max_pfn);
+	}


Thanks
Atsushi Kumagai