Bug 489147

> It should show the data of struct shared_info since 0xf545c000 is
> (shared_info_t *).

The capability of accessing "fixmap" hypervisor address space has never
been available, either running on the live system or against a vmcore.

The closest you can come to it is to read it as "machine" memory.

  crash> p *xen_start_info
  $10 = {
    magic = "xen-3.1-x86_64\000\000\000\000\000\000\000\000\000\000\000\000\000  
    \000\000\000\000", 
    nr_pages = 0x32a7a, 
    shared_info = 0xfe3000, 
    flags = 0x3,
    store_mfn = 0x3ca52, 
    store_evtchn = 0x7, 
    ...

  crash> rd -m 0xfe3000 <count>
  ...

I think it may be possible to access it if the pseudo-physical address
associated with machine address 0xfe3000 can be determined, but there's
no "m2p" functionality available in the crash utility, because with that
value, a "ptov" could be done on the pseudo-physical address to come up
with a unity-mapped kernel virtual address.  Then again, if the pseudo
physical address were above "highmem", that wouldn't work on a 32-bit x86.

> I think it may be possible to access it if the pseudo-physical address
> associated with machine address 0xfe3000 can be determined, but there's
> no "m2p" functionality available in the crash utility ...

No, as it turns out, that won't work either, because there is no entry in
the kernel's p2m table for that machine address.  That's why the read fails.

Note also that fixmap virtual addresses have never been readily accessible
from the crash utility -- in normal kernels (as well as in xen kernels).

> The closest you can come to it is to read it as "machine" memory.
> 
>   crash> p *xen_start_info
>   $10 = {
>     magic = "xen-3.1-x86_64\000\000\000\000\000\000\000\000\000\000\000\000\000 
>     \000\000\000\000", 
>     nr_pages = 0x32a7a, 
>     shared_info = 0xfe3000, 
>     flags = 0x3,
>     store_mfn = 0x3ca52, 
>     store_evtchn = 0x7, 
>     ...
> 
>   crash> rd -m 0xfe3000 <count>
>   ...

First thank you very much for making crash available. it's excellent tool, I use it everyday.
I tried above command, but rd failed again.
crash> p *xen_start_info
$4 = {
  magic = "xen-3.0-x86_32p\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
  nr_pages = 0x60000,
  shared_info = 0xbd0000,
  flags = 0x0,
------------
crash> rd -m 0xbd0000 8
rd: read error: xen machine address: bd0000  type: "32-bit XENMACHADDR"

(In reply to comment #3)
> Note also that fixmap virtual addresses have never been readily accessible
> from the crash utility -- in normal kernels (as well as in xen kernels).  

The xen kernel sets up page tables for fixmap address. Then I think crash utility can read it based on page tables. Isn't crash tool use page tables to decode a kernel virtual address(0xc000,0000 - 0xffffffff in install 32bit)?

> crash> p *xen_start_info
> $4 = {
>   magic =
> "xen-3.0-x86_32p\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000",
>   nr_pages = 0x60000,
>   shared_info = 0xbd0000,
>   flags = 0x0,
> ------------
> crash> rd -m 0xbd0000 8
> rd: read error: xen machine address: bd0000  type: "32-bit XENMACHADDR" 

If that's the case, then the page associated with machine address bd0000
is not included in the vmcore file at all.  There's nothing that can be
done about that.  (I was able to access it with an x86_64 xen dump)

> The xen kernel sets up page tables for fixmap address. Then I think crash
> utility can read it based on page tables. Isn't crash tool use page tables to
> decode a kernel virtual address(0xc000,0000 - 0xffffffff in install 32bit)?  

For xen kernels, the virtual address is first translated to a pseudo-physical
address, and then the vmcore's m2p notes section is accessed to determine which
machine address that the pseudo-physical address corresponds to.  In your
case, the page was not included in the dumpfile.