Itsuro ODA wrote: I'm still downloading the above, so I haven't been able to test it yet... This all sounds good, and I agree that the p2m_mfn should be added to the ia64 XEN_ELFNOTE_CRASH_INFO. However, there's something incorrect in your calculation of "xkd->p2m_frames" in your ia64_xen_kdump_p2m_create() implementation. It looks like it should be 32, but it's set to 524288. As a result that wastes a lot of memory, and "help -n" is pretty much unusable since wants to dump all ~512k entries: $ ./crash vmlinux-xen-ia64 vmcore.tiger.iomem_machine ... crash> help -n ... xen_kdump_data: flags: 5 (KDUMP_P2M_INIT|KDUMP_MFN_LIST) p2m_mfn: 1f62c cr3: 0 last_mfn_read: 1fd09 page: 6000000000c96bd0 accesses: 1340 cache_hits: 1255 (95%) p2m_frames: 524288 p2m_mfn_frame_list: 200000000539c010 1efba 1f5cc 1fd09 1e185 1d984 1d183 1c982 1c181 1b980 1b17f 1a97e 1a17d 1997c 1917b 1897a 18179 17978 17177 16976 16175 15974 15173 14972 14171 13970 1316f 1296e 1216d 1196c 1116b 1096a 10169 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1efb8 1efb7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1efb6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 If you enter "crash -d2", you'll also see all 512k, mostly useless, entries... Dave

Dave Anderson wrote: And finally... I don't understand what check_netdump_xen() and check_kdump_xen() are for. Both of them check whether "xen_kdump_data.p2m_mfn" has been initialized, and if so, they to initialize several things that should already have been initialized when xen_kdump_data.p2m_mfn was originally set? Are they ia64 only? Or are they *only* necessary for the strange case where the --p2m_mfn over-ride is used on that kludged-up netdump-to-kdump vmcore? I still don't understand how that dumpfile was even created -- should we even worry about that type of dumpfile even existing? Dave

Hi, My calculation was wrong. "256GB-" and "-16TB". So my patch always consumes large amount of memory... It is not good. (though the patch is usefull actually now) As I said: But this may be wrong. I hope my patch helps to understand IA64's phys-to-machine mapping structure... Thanks. -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Hi Dave. I think I can explain it. Sometimes xen needs to share pages with dom0. For example shared_info, grant table pages, another domain's pages and etc. In such a case, Xen/IA64 puts those pages in the dom0 pseudo physical addresses space, i.e. it updates dom0 p2m table, thus dom0 can access those pages. Pseudo physical addresses are predefined or given by xen or dom0. Currently shared_info is assigned at pseudo physical address of 1UL << 40 = 1TB. This corresponds to the following entry. Dom0 controls devices so that it needs to access I/O area. For that purpose, dom0 p2m table has the entry which points I/O area such that dom0 pseudo physical address = machine address. I guess that the following entry corresponds to I/O area. In order to confirm this, The native linux's /proc/iomem is necessary. thanks. On Fri, May 11, 2007 at 10:02:39AM -0400, Dave Anderson wrote: > Itsuro ODA wrote: > > Hi Dave, > > > This all sounds good, and I agree that the p2m_mfn should > > be added to the ia64 XEN_ELFNOTE_CRASH_INFO. > > > > However, there's something incorrect in your calculation of > > "xkd->p2m_frames" in your ia64_xen_kdump_p2m_create() implementation. > > It looks like it should be 32, but it's set to 524288. As a result > > that wastes a lot of memory, and "help -n" is pretty much unusable > > since wants to dump all ~512k entries: > > This is because IA64's pseudo-physical memory map (domain on xen > specific). > > phys-to-machine mapping is managed as 3-level page table. > pgd looks like: > ------------------------------------------------------------- > crash> doms > DID DOMAIN ST T MAXPAGE TOTPAGE VCPU SHARED_I > P2M_MFN > 32753 f000000007dac080 ?? O 0 0 0 0 > ---- > 32754 f000000007ff0080 ?? X 0 0 0 0 > ---- > 32767 f000000007ff4080 ?? I 0 0 1 0 > ---- > >* 0 f000000007da4080 ?? 0 10000 f986 1 f000000007d90000 > 1f62c > > crash> domain f000000007da4080 > struct domain { > domain_id = 0, > shared_info = 0xf000000007d90000, > ... > arch = { > mm = { > pgd = 0xf00000007d8b0000 > }, > ... > crash> rd 0xf00000007d8b0000 256 > f00000007d8b0000: 000000007c8d8000 0000000000000000 ...|............ > f00000007d8b0010: 0000000000000000 0000000000000000 ................ > f00000007d8b0020: 0000000000000000 0000000000000000 ................ > f00000007d8b0030: 0000000000000000 0000000000000000 ................ > f00000007d8b0040: 0000000000000000 0000000000000000 ................ > f00000007d8b0050: 0000000000000000 0000000000000000 ................ > f00000007d8b0060: 0000000000000000 0000000000000000 ................ > f00000007d8b0070: 0000000000000000 0000000000000000 ................ > f00000007d8b0080: 000000007f428000 0000000000000000 ..B............. > f00000007d8b0090: 0000000000000000 0000000000000000 ................ > ... > f00000007d8b07c0: 0000000000000000 0000000000000000 ................ > f00000007d8b07d0: 0000000000000000 0000000000000000 ................ > f00000007d8b07e0: 0000000000000000 0000000000000000 ................ > ------------------------------------------------------------------------- > (256 * 2048 = 524288) > > It is certain that (pseudo-)physical memory "256GB-" and "-4TB" exits. > These area are shared by domain-0 and xen hypervisor. > These area should be accessed in dom0's analysis session. > > (I said:) > > > But this patch is a bit tricky. And the memory usage is > > > large if the machine memory layout is sparse. > > It is wrong. This should be "the memory usage is large if > pseudo-physical memory layout is sparse." > And it is always sparse actually... > > Thanks. > > > Hi Itsuro, > > I now understand the difference in the 3rd-level p2m > frame contents being page table entries instead of mfn > values. > > However, I still do not understand what you mean regarding > the concept of the pseudo-physical memory being "sparse". > Looking at the dumpfile again, it appears to have the same > type of flat pseudo-physical memory layout just like the > other architectures. > > Dom0 has ~1GB of pseudo-physical memory: > > crash> sys > KERNEL: ../20070510-sample-dump-2/vmlinux-xen-ia64 > DUMPFILE: ../20070510-sample-dump-2/vmcore.tiger.iomem_machine > CPUS: 1 > DATE: Mon May 7 04:07:43 2007 > UPTIME: 00:01:47 > LOAD AVERAGE: 0.11, 0.04, 0.01 > TASKS: 21 > NODENAME: (none) > RELEASE: 2.6.18-xen > VERSION: #3 SMP Mon May 7 13:14:41 JST 2007 > MACHINE: ia64 (1296 Mhz) > MEMORY: 1 GB > PANIC: "SysRq : Trigger a crashdump" > crash> > > And as far as dom0's VM is concerned, its memory map only knows > about the 64512 pages in DMA zone 0: > > crash> kmem -n > NODE SIZE PGLIST_DATA BOOTMEM_DATA NODE_ZONES > 0 64512 a000000100482f80 a000000100608950 a000000100482f80 > a000000100483500 > a000000100483a80 > a000000100484000 > MEM_MAP START_PADDR START_MAPNR > e0000000010b0000 0 0 > > ZONE NAME SIZE MEM_MAP START_PADDR START_MAPNR > 0 DMA 64512 e0000000010b0000 0 0 > 1 DMA32 0 0 0 0 > 2 Normal 0 0 0 0 > 3 HighMem 0 0 0 0 > crash> > > So the "end of memory" would be just below 1GB: > > crash> eval 64512 * 16k > hexadecimal: 3f000000 (1008MB) > decimal: 1056964608 > octal: 7700000000 > binary: 0000000000000000000000000000000000111111000000000000000000000000 > crash> > > So, with respect to dom0, how would it ever go beyond 32 > p2m_frames? Putting a debug printf in xen_kdump_p2m, it > shows this: > > crash> rd -p 3f000000 > xen_kdump_p2m: mfn_idx for 3f000000: 31 > 3f000000: 0000000000000000 ........ > crash> > > So that shows that there only needs to be 32 p2m_frames > for accessing all of dom0 pseudo-physical memory. > > But it also shows that you are allowing access to memory > that is *beyond* the end of dom0 pseudo-physical memory, > since 3f000000 should not be readable. There is not a > page structure associated with 3f000000: > > crash> kmem -p | tail > e000000001421dd0 3efd8000 ------- ----- 1 0 > e000000001421e08 3efdc000 ------- ----- 1 0 > e000000001421e40 3efe0000 ------- ----- 1 60 > e000000001421e78 3efe4000 ------- ----- 1 60 > e000000001421eb0 3efe8000 ------- ----- 1 60 > e000000001421ee8 3efec000 ------- ----- 1 60 > e000000001421f20 3eff0000 ------- ----- 2 0 > e000000001421f58 3eff4000 ------- ----- 1 80 > e000000001421f90 3eff8000 ------- ----- 1 80 > e000000001421fc8 3effc000 ------- ----- 1 80 > crash> > > By doing few other "rd -p" commands, I see that you seem > to be allowing memory accesses based upon what's in the ELF > header PT_LOAD segments, which are "machine" physical memory > descriptors: > > crash> help -n | grep phys_end > phys_end: 1000 > phys_end: 7000 > phys_end: 9000 > phys_end: 82000 > phys_end: 85000 > phys_end: a0000 > phys_end: 4000000 > phys_end: 81b3000 > phys_end: ffc0000 > phys_end: 10000000 > phys_end: 7ab06000 > phys_end: 7c8d2000 > phys_end: 7c92e000 > phys_end: 7c938000 > phys_end: 7c97e000 > phys_end: 7cdf6000 > phys_end: 7cdfc000 > phys_end: 7ce2a000 > phys_end: 7d001000 > phys_end: 7d002000 > phys_end: 7d044000 > phys_end: 7d045000 > phys_end: 7d37e000 > phys_end: 7d700000 > phys_end: 7d77e000 > phys_end: 7d8b4000 > phys_end: 7f980000 > phys_end: 7fa00000 > phys_end: 7feda000 > crash> > > So it appears that the physical machine running the > dom0 and hypervisor has almost 2GB of "real" physical > memory. And if I try to read the limit address of > 7feda000, it fails: > > crash> rd -p 7feda000 > xen_kdump_p2m: mfn_idx for 7feda000: 63 > rd: read error: physical address: 7feda000 type: "64-bit PHYSADDR" > crash> > > But the last page of physical memory can be read: > > crash> rd -p 7fed9000 > xen_kdump_p2m: mfn_idx for 7fed9000: 63 > 7fed9000: 000000007f9da0a0 ........ > crash> > > "rd -p" is supposed to read pseudo-physical memory in xen > kernels, but it seems to be allowing reads based upon the > PT_LOAD segment contents? In other words, it seems to > be mixing dom0 pseudo-physical memory and the system's > machine memory, because 7fed9000 is not a legitimate dom0 > pseudo-physical address. > > (And even with that happening, the maximum p2m_frame index > is still only 63 -- how can it ever be 512k with respect > to dom0's pseudo-physical memory?) > > So I'm sorry, but this does not make sense to me... > > Dave > > > -- yamahata

Hi, Thanks for your explanation, Isaku. I understand the first 1GB(for this example) is necessary for looking ordinal linux kernel structures. I feel now it is better to make p2m_frame table for the first contiguous physical address space which is treated as RAM, and make special command to look the shared_info area or io space if it is necessary. Let me consider for a while. (I can't access any IA64 environment right now.) I will reply early next week. Thanks. Dave Anderson said: > Isaku Yamahata wrote: > >> Hi Dave. >> I think I can explain it. >> >> Sometimes xen needs to share pages with dom0. >> For example shared_info, grant table pages, another domain's pages >> and etc. >> In such a case, Xen/IA64 puts those pages in the dom0 pseudo physical >> addresses space, i.e. it updates dom0 p2m table, thus dom0 can >> access those pages. >> Pseudo physical addresses are predefined or given by xen or dom0. >> Currently shared_info is assigned at pseudo physical address >> of 1UL << 40 = 1TB. >> This corresponds to the following entry. >> > f00000007d8b0080: 000000007f428000 0000000000000000 >> ..B............. >> >> Dom0 controls devices so that it needs to access I/O area. >> For that purpose, dom0 p2m table has the entry which points I/O area >> such that dom0 pseudo physical address = machine address. >> I guess that the following entry corresponds to I/O area. >> > f00000007d8b07f0: 0000000000000000 000000007bed4000 >> .........@.{.... >> In order to confirm this, The native linux's /proc/iomem is necessary. >> >> thanks. >> > > OK, thanks for that explanation... > > It *still* seems to be a huge waste of memory. Taking the > example dump, the 1GB of "normal" memory requires 32 p2m_mfn > values for address translation, plus -- if I understand you > correctly -- 1 for the shared_info, plus 1 for the I/O area. > That's a total of 34 8-byte values, or 272 bytes. Whereas > this first patch uses 524288 entries, or 4MB of memory. > It seems to me there should be a better way to handle it, > even if those two particular pseudo-physical regions are > "special-cased" for ia64. > > > Thanks guys, > Dave > > >> >> On Fri, May 11, 2007 at 10:02:39AM -0400, Dave Anderson wrote: >> > Itsuro ODA wrote: >> > >> > Hi Dave, >> > >> > > This all sounds good, and I agree that the p2m_mfn should >> > > be added to the ia64 XEN_ELFNOTE_CRASH_INFO. >> > > >> > > However, there's something incorrect in your calculation of >> > > "xkd->p2m_frames" in your ia64_xen_kdump_p2m_create() >> implementation. >> > > It looks like it should be 32, but it's set to 524288. As a >> result >> > > that wastes a lot of memory, and "help -n" is pretty much >> unusable >> > > since wants to dump all ~512k entries: >> > >> > This is because IA64's pseudo-physical memory map (domain on xen >> > specific). >> > >> > phys-to-machine mapping is managed as 3-level page table. >> > pgd looks like: >> > ------------------------------------------------------------- >> > crash> doms >> > DID DOMAIN ST T MAXPAGE TOTPAGE VCPU SHARED_I >> > P2M_MFN >> > 32753 f000000007dac080 ?? O 0 0 0 0 >> > ---- >> > 32754 f000000007ff0080 ?? X 0 0 0 0 >> > ---- >> > 32767 f000000007ff4080 ?? I 0 0 1 0 >> > ---- >> > >* 0 f000000007da4080 ?? 0 10000 f986 1 >> f000000007d90000 >> > 1f62c >> > >> > crash> domain f000000007da4080 >> > struct domain { >> > domain_id = 0, >> > shared_info = 0xf000000007d90000, >> > ... >> > arch = { >> > mm = { >> > pgd = 0xf00000007d8b0000 >> > }, >> > ... >> > crash> rd 0xf00000007d8b0000 256 >> > f00000007d8b0000: 000000007c8d8000 0000000000000000 >> ...|............ >> > f00000007d8b0010: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0020: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0030: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0040: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0050: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0060: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0070: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b0080: 000000007f428000 0000000000000000 >> ..B............. >> > f00000007d8b0090: 0000000000000000 0000000000000000 >> ................ >> > ... >> > f00000007d8b07c0: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b07d0: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b07e0: 0000000000000000 0000000000000000 >> ................ >> > f00000007d8b07f0: 0000000000000000 000000007bed4000 >> .........@.{.... >> > ------------------------------------------------------------------------- >> > (256 * 2048 = 524288) >> > >> > It is certain that (pseudo-)physical memory "256GB-" and "-4TB" >> exits. >> > These area are shared by domain-0 and xen hypervisor. >> > These area should be accessed in dom0's analysis session. >> > >> > (I said:) >> > > > But this patch is a bit tricky. And the memory usage is >> > > > large if the machine memory layout is sparse. >> > >> > It is wrong. This should be "the memory usage is large if >> > pseudo-physical memory layout is sparse." >> > And it is always sparse actually... >> > >> > Thanks. >> > >> > >> > Hi Itsuro, >> > >> > I now understand the difference in the 3rd-level p2m >> > frame contents being page table entries instead of mfn >> > values. >> > >> > However, I still do not understand what you mean regarding >> > the concept of the pseudo-physical memory being "sparse". >> > Looking at the dumpfile again, it appears to have the same >> > type of flat pseudo-physical memory layout just like the >> > other architectures. >> > >> > Dom0 has ~1GB of pseudo-physical memory: >> > >> > crash> sys >> > KERNEL: ../20070510-sample-dump-2/vmlinux-xen-ia64 >> > DUMPFILE: ../20070510-sample-dump-2/vmcore.tiger.iomem_machine >> > CPUS: 1 >> > DATE: Mon May 7 04:07:43 2007 >> > UPTIME: 00:01:47 >> > LOAD AVERAGE: 0.11, 0.04, 0.01 >> > TASKS: 21 >> > NODENAME: (none) >> > RELEASE: 2.6.18-xen >> > VERSION: #3 SMP Mon May 7 13:14:41 JST 2007 >> > MACHINE: ia64 (1296 Mhz) >> > MEMORY: 1 GB >> > PANIC: "SysRq : Trigger a crashdump" >> > crash> >> > >> > And as far as dom0's VM is concerned, its memory map only knows >> > about the 64512 pages in DMA zone 0: >> > >> > crash> kmem -n >> > NODE SIZE PGLIST_DATA BOOTMEM_DATA NODE_ZONES >> > 0 64512 a000000100482f80 a000000100608950 a000000100482f80 >> > a000000100483500 >> > a000000100483a80 >> > a000000100484000 >> > MEM_MAP START_PADDR START_MAPNR >> > e0000000010b0000 0 0 >> > >> > ZONE NAME SIZE MEM_MAP START_PADDR START_MAPNR >> > 0 DMA 64512 e0000000010b0000 0 0 >> > 1 DMA32 0 0 0 0 >> > 2 Normal 0 0 0 0 >> > 3 HighMem 0 0 0 0 >> > crash> >> > >> > So the "end of memory" would be just below 1GB: >> > >> > crash> eval 64512 * 16k >> > hexadecimal: 3f000000 (1008MB) >> > decimal: 1056964608 >> > octal: 7700000000 >> > binary: >> 0000000000000000000000000000000000111111000000000000000000000000 >> > crash> >> > >> > So, with respect to dom0, how would it ever go beyond 32 >> > p2m_frames? Putting a debug printf in xen_kdump_p2m, it >> > shows this: >> > >> > crash> rd -p 3f000000 >> > xen_kdump_p2m: mfn_idx for 3f000000: 31 >> > 3f000000: 0000000000000000 ........ >> > crash> >> > >> > So that shows that there only needs to be 32 p2m_frames >> > for accessing all of dom0 pseudo-physical memory. >> > >> > But it also shows that you are allowing access to memory >> > that is *beyond* the end of dom0 pseudo-physical memory, >> > since 3f000000 should not be readable. There is not a >> > page structure associated with 3f000000: >> > >> > crash> kmem -p | tail >> > e000000001421dd0 3efd8000 ------- ----- 1 0 >> > e000000001421e08 3efdc000 ------- ----- 1 0 >> > e000000001421e40 3efe0000 ------- ----- 1 60 >> > e000000001421e78 3efe4000 ------- ----- 1 60 >> > e000000001421eb0 3efe8000 ------- ----- 1 60 >> > e000000001421ee8 3efec000 ------- ----- 1 60 >> > e000000001421f20 3eff0000 ------- ----- 2 0 >> > e000000001421f58 3eff4000 ------- ----- 1 80 >> > e000000001421f90 3eff8000 ------- ----- 1 80 >> > e000000001421fc8 3effc000 ------- ----- 1 80 >> > crash> >> > >> > By doing few other "rd -p" commands, I see that you seem >> > to be allowing memory accesses based upon what's in the ELF >> > header PT_LOAD segments, which are "machine" physical memory >> > descriptors: >> > >> > crash> help -n | grep phys_end >> > phys_end: 1000 >> > phys_end: 7000 >> > phys_end: 9000 >> > phys_end: 82000 >> > phys_end: 85000 >> > phys_end: a0000 >> > phys_end: 4000000 >> > phys_end: 81b3000 >> > phys_end: ffc0000 >> > phys_end: 10000000 >> > phys_end: 7ab06000 >> > phys_end: 7c8d2000 >> > phys_end: 7c92e000 >> > phys_end: 7c938000 >> > phys_end: 7c97e000 >> > phys_end: 7cdf6000 >> > phys_end: 7cdfc000 >> > phys_end: 7ce2a000 >> > phys_end: 7d001000 >> > phys_end: 7d002000 >> > phys_end: 7d044000 >> > phys_end: 7d045000 >> > phys_end: 7d37e000 >> > phys_end: 7d700000 >> > phys_end: 7d77e000 >> > phys_end: 7d8b4000 >> > phys_end: 7f980000 >> > phys_end: 7fa00000 >> > phys_end: 7feda000 >> > crash> >> > >> > So it appears that the physical machine running the >> > dom0 and hypervisor has almost 2GB of "real" physical >> > memory. And if I try to read the limit address of >> > 7feda000, it fails: >> > >> > crash> rd -p 7feda000 >> > xen_kdump_p2m: mfn_idx for 7feda000: 63 >> > rd: read error: physical address: 7feda000 type: "64-bit PHYSADDR" >> > crash> >> > >> > But the last page of physical memory can be read: >> > >> > crash> rd -p 7fed9000 >> > xen_kdump_p2m: mfn_idx for 7fed9000: 63 >> > 7fed9000: 000000007f9da0a0 ........ >> > crash> >> > >> > "rd -p" is supposed to read pseudo-physical memory in xen >> > kernels, but it seems to be allowing reads based upon the >> > PT_LOAD segment contents? In other words, it seems to >> > be mixing dom0 pseudo-physical memory and the system's >> > machine memory, because 7fed9000 is not a legitimate dom0 >> > pseudo-physical address. >> > >> > (And even with that happening, the maximum p2m_frame index >> > is still only 63 -- how can it ever be 512k with respect >> > to dom0's pseudo-physical memory?) >> > >> > So I'm sorry, but this does not make sense to me... >> > >> > Dave >> > >> > >> > >> >> > -- >> > Crash-utility mailing list >> > Crash-utility(a)redhat.com >> > https://www.redhat.com/mailman/listinfo/crash-utility >> >> -- >> yamahata >> >> -- >> Crash-utility mailing list >> Crash-utility(a)redhat.com >> https://www.redhat.com/mailman/listinfo/crash-utility > -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Hi, On Sat, 12 May 2007 22:24:53 +0900 Isaku Yamahata <yamahata(a)valinux.co.jp&gt; wrote: I see. So I separate p2m conversion for IA64 from the common code simply. The new patch is attached. * only pgd is in core. * read pdm entry each time * the last page table read is cached How about it ? (I found the shared_info area can't be accessed any way. I will investigate how to display it.) Thanks. -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Hi Dave, Yes. Thanks. On Mon, 14 May 2007 16:33:43 -0400 Dave Anderson <anderson(a)redhat.com&gt; wrote: > Itsuro ODA wrote: > > > Hi, > > > > On Sat, 12 May 2007 22:24:53 +0900 > > Isaku Yamahata <yamahata(a)valinux.co.jp&gt; wrote: > > > > > There is no gurantee that RAM is contiguous in dom0 pseudo > > > physical address space. It might be sparse or discontiguous. > > > > I see. > > > > So I separate p2m conversion for IA64 from the common code > > simply. The new patch is attached. > > * only pgd is in core. > > * read pdm entry each time > > * the last page table read is cached > > > > How about it ? > > > > Nice! > > > Thanks, > Dave > > > > > > (I found the shared_info area can't be accessed any way. > > I will investigate how to display it.) > > > > Thanks. > > -- > > Itsuro ODA <oda(a)valinux.co.jp&gt; > > > > ------------------------------------------------------------------------------------------------------------------------ > > Name: diff-20070514 > > diff-20070514 Type: unspecified type (application/octet-stream) > > Encoding: base64 > -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Hi Dave, On Tue, 15 May 2007 10:33:14 -0400 Dave Anderson <anderson(a)redhat.com&gt; wrote: OK, it looks good. Thanks -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Hi Dave, On Thu, 10 May 2007 15:27:34 -0400 Dave Anderson <anderson(a)redhat.com&gt; wrote: Sorry. (I have forgoten that I put .debug file into /usr/lib/debug/boot in my environment.) I attached .debug file in this mail. (I put it into 20070510-sample-dump-1.tar too.) Right, there is no customer. The sample vmcore was taken by fujitsu's "sadump" tool which is a hardware assist tool. Putting the dump button casuse INIT inerrupt and then registers are saved and CPUs stop. The hardware dumps all memory after that. The memory image is converted to ELF vmcore (netdump style) finally. It is hard to add XEN_ELFNOTE_CRASH_INFO notes in this procedure (I think). (I think it is easy to change to converting kdump style.) I will ask to fujitsu's people whether it is available. It is for IA64 machine now. I don't know X86/X86_64 machine will be supported. Yes. Illegal input to "rd" causes SIGSEGV. This is a page table. The 3rd level table contains page table entry. IA64 manages phys-to-machine mapping different way from x86/x86_64. It is a 3-level page table. p2m_mfn containd in XEN_ELFNOTE_CRASH_INFO is the mfn of the top level page table (ie. pgd). The only same thing is "3-level". (So I said "tricky".) -- Itsuro ODA <oda(a)valinux.co.jp&gt;

Akio Takebe wrote: OK, I understand. This is the first time I've ever heard of the Fujitsu "sadump" facility. The function name "check_netdump_xen()" is confusing because the "real" netdump facility and xen kernels don't have any relationship. So I'd prefer to make it easier to understand what's going on by doing something like this in main(): } else if (is_netdump(argv[optind], NETDUMP_LOCAL)) { if (pc->flags & MEMORY_SOURCES) { error(INFO, "too many dumpfile arguments\n"); program_usage(SHORT_FORM); } pc->flags |= NETDUMP; pc->dumpfile = argv[optind]; if (is_sadump_xen()) { pc->readmem = read_kdump; pc->writemem = write_kdump; } else { pc->readmem = read_netdump; pc->writemem = write_netdump; } } and then make is_sadump_xen() do this: /* * Fujitsu dom0/HV sadump-generated dumpfile, which requires * the --p2m_mfn command line argument. */ int is_sadump_xen() { if (xen_kdump_data.p2m_mfn) { if (!XEN_CORE_DUMPFILE()) { pc->flags |= XEN_CORE; nd->xen_kdump_data = &xen_kdump_data; nd->xen_kdump_data->last_mfn_read = BADVAL; nd->xen_kdump_data->flags |= KDUMP_MFN_LIST; } return TRUE; } return FALSE; } Does that seem reasonable? Dave