[Crash-utility] ARM support for CONFIG_SPARSEMEM: (was Re:DDimage)

[Dave Anderson]

----- Original Message -----
> On Thu, May 26, 2011 at 11:53 AM, <takuo.koguchi.sw at hitachi.com> wrote:

> > It might come form my vmcore file's incorrectness.
> > Currently my vmcore contains the following,
> > Program Headers:
> >  Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> >  NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
> >  LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0
> >
> > But actual mapping is,
> > Virtual 0xc0000000-0xcfffffff corresponds Physical 0x00000000-0x0fffffff
> > and
> > Virtual 0xd0000000-0xdfffffff corresponds Physical 0x40000000-0x4fffffff
> >
> > Then I tried to prepend the following header instead, 
> > Program Headers:
> >  Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> >  NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
> >  LOAD 0x000094 0xc0000000 0x00000000 0x10000000 0x10000000 RWE 0
> >  LOAD 0x10000094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0
> >
> > This time crash does not recognize the vmcore file.
> >
> > Perhaps I have to change VTOP/PTOV macros accordingly?
> 
> It should be enough if you have machdep->machspec->phys_base set to
> correct value, which is 0 in your case. You can see this by running
> 'crash -d1 ...'. Also if possible, can you post the full output here
> so that we can analyze it further.

Hey guys,

Pardon my confusion/interruption, but the "actual mapping" above would 
be unique for unity-mapping.  The 0xc0000000-0xcfffffff segment is 
"traditionally" unity-mapped, where VTOP() would strip off the kvbase,
and then apply a physical base if appropriate.  But then the second
0xd0000000-0xdfffffff segment could not use the same logic.

Looking at the upstream ARM sources, __pa() is:

  #define __pa(x)                 __virt_to_phys((unsigned long)(x))

where __virt_to_phys() does something different if CONFIG_ARM_PATCH_PHYS_VIRT
is configured:

  #ifdef CONFIG_ARM_PATCH_PHYS_VIRT
  
  /*
   * Constants used to force the right instruction encodings and shifts
   * so that all we need to do is modify the 8-bit constant field.
   */
  #define __PV_BITS_31_24	0x81000000
  #define __PV_BITS_23_16	0x00810000
  
  extern unsigned long __pv_phys_offset;
  #define PHYS_OFFSET __pv_phys_offset
  
  #define __pv_stub(from,to,instr,type)			\
  	__asm__("@ __pv_stub\n"				\
  	"1:	" instr "	%0, %1, %2\n"		\
  	"	.pushsection .pv_table,\"a\"\n"		\
  	"	.long	1b\n"				\
  	"	.popsection\n"				\
  	: "=r" (to)					\
  	: "r" (from), "I" (type))
  
  static inline unsigned long __virt_to_phys(unsigned long x)
  {
  	unsigned long t;
  	__pv_stub(x, t, "add", __PV_BITS_31_24);
  #ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
  	__pv_stub(t, t, "add", __PV_BITS_23_16);
  #endif
  	return t;
  }
  
  static inline unsigned long __phys_to_virt(unsigned long x)
  {
  	unsigned long t;
  	__pv_stub(x, t, "sub", __PV_BITS_31_24);
  #ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
  	__pv_stub(t, t, "sub", __PV_BITS_23_16);
  #endif
  	return t;
  }
  #else
  #define __virt_to_phys(x)	((x) - PAGE_OFFSET + PHYS_OFFSET)
  #define __phys_to_virt(x)	((x) - PHYS_OFFSET + PAGE_OFFSET)
  #endif

Is that what's happening here?  I don't understand the __pv_stub()
stuff, but if the virtual-to-physical unity-mapping is as Takuo
described, then there would have to be a change to the ARM VTOP/PTOV 
macros.

Anyway, as to why crash doesn't recognize the vmcore with the second
PT_LOAD segment added, you'll have to debug why is_netdump() is
rejecting it.

Dave