[Crash-utility] Problems debugging live system with 4.0-2.24 crash

Dave Anderson anderson at redhat.com
Mon May 8 15:42:48 UTC 2006


"Graham, Simon" wrote:

> Thanks for the info Dave - maybe this belongs in the appropriate Xen list, but this code seems fundamentally broken to
> me for a couple of reasons:
>
>   1. I'm pretty sure that the address passed into read_mem is a physical address NOT a machine-address and yet the
>      code in is_local_lowmem seems to treat this as an mfn (at least, I would assume that mfn_to_local_pfn would be
>      doing so)
>   2. That aside, it just seems wrong to me to break the operation of /dev/mem so that the one thing it _cant_ return
>      is low memory for the guest!
>
> Time for a Xen bug I think!
>
> Simon
>

You're preaching to the choir, man...

And I believe you're right -- it does seem to be a bug rather than
a feature, unless whatever user processes that utilize /dev/mem are
supposed to have some kind of pre-knowledge of the machine addresses
behind the pseudo-physical address?  How can that be?


> /*
>  * Does @address reside within a non-highmem page that is local to this virtual
>  * machine (i.e., not an I/O page, nor a memory page belonging to another VM).
>  * See the comment that accompanies mfn_to_local_pfn() in page.h to understand
>  * why this works.
>  */
> static inline int is_local_lowmem(unsigned long address)
> {
>         extern unsigned long max_low_pfn;
>         return (mfn_to_local_pfn(address >> PAGE_SHIFT) < max_low_pfn);
> }
>
I've always been under the impression that addresses passed into
/dev/mem are by definition be pseudo-physical addresses; and that the
PTE entry used to map them would be subsequently over-written by the
hypervisor for kernels with writable page tables.

But in any case, early on I moved on from /dev/mem to using /dev/crash
like for RHEL4, and never really noticed what you've discovered.

Dave




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060508/c56409be/attachment.htm>


More information about the Crash-utility mailing list