On Mon, 29 Sep 2014 17:04:32 +0800 Baoquan He <bhe at redhat.com> wrote: > On 09/26/14 at 01:34pm, Michael Holzheu wrote: > > On Fri, 26 Sep 2014 16:55:46 +0800 > > > > > Isn't this a chicken-and-egg problem? In order to determine vmalloc start > > > > I have to be able to read memory. But in order to read memory I have > > > > to call get_kcore_dump_loads() first. > > > > > > > > What about using /proc/iomem to find out if an address is a real address? > > > > > > Well, that's good it works for s390. Anyway in get_kcore_dump_loads() it > > > just gets the physical ram region, and filter out the unwanted region, > > > so your method is good. In x86_64, the is_vmalloc_addr_x86_64 is not > > > only filtering the vmalloc, but vmmemmap and modules_vaadr region. For > > > simplicity it's only named as is_vmalloc_addr. > > > > Not sure if I understood, why ths is_real_addr() function does not > > work for x86_64. > > > > Also for x86 all three areas, vmalloc, vmemmap, and modules_vaddr, are > > virtual memory regions with addresses outside of the the memory ranges > > where /proc/iommem reports physical memory, right? > > > > So the new is_real_addr() function should return false for that areas. > > is_real_addr() should work for x86_64, this almost does the way > kexec-tools is doing. Originally I just consider this for x86_64, > skipped other ARCHs. From x86_64 point of view, processing kcore only > need to pick up the program segments we want. If it's hard to handle it, > I am fine with it that you use the is_real_addr to do it. But please > don't use this name, it could be is_phy_addr() or somthing like that. > Please post your patch and test x86_64 too and we can review it. > > In fact the other way is wrapping your is_real_addr() to > is_vmalloc_addr_s390(), and make it work for s390. If later other ARCH > also has this requirements, raise it to be common function. Anyway it's > fine to me if it can work. Hi Baoquan, Because I don't have the possibility to test on x86_64 I decided to make a s390x only patch. I will send it with the next note. Thanks for your help! Michael
