[...]
>>
>> 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
