Re: [Crash-utility] dom0cut script updated

Kazuo Moriwaka wrote: Yay! In my prototype, I did not need shared_info.arch.max_pfn because the page that the pfn_to_mfn_frame_list_list mfn references can only contain a hardwired number of entries, i.e., 16 on x86, and 512 on x86_64: arch/i386/kernel/setup-xen.c: unsigned long *pfn_to_mfn_frame_list[16]; arch/x86_64/kernel/setup-xen.c: unsigned long *pfn_to_mfn_frame_list[512]; So I can just walk through the array, and stop on either (1) a zero-filled entry, or (2) the end of the array. All I need to know is what the new ELF note "NT_xxx" n_type value will be. Recall that in your test vmcore last June, you used an n_type value of 0x10000001, which meant that you were passing a cr3 value. The only other non-standard NT_xxx value recognized by the crash utility is the diskdump-specific NT_DISKDUMP note (0x70000001). Right, I understand. Just having dom0's pfn_to_mfn_frame_list_list mfn would be great. Right -- I understand. Again, as far as the new ELF note is concerned, just the dom0 mfn would be great. If it were absolutely necessary to bring up a session for one of the domU sessions, their per-domU mfn values could be determined later by: (1) dom0cut the /proc/vmcore to make a xen vmcore, and get the domU mfns from there, or (2) perhaps a quick-and-dirty utility could be written that digs out the mfn values from the original vmcore, by using the xen data structures/symbols, and then just dumps them out to the screen? In any case, having determined the mfn for any of the domU sessions, a new crash command line option could be created to pass in any of the domU mfn values, which could over-ride the dom0 mfn value in the new ELF note. But again, just having dom0's mfn would be outstanding. Thanks, Dave