Re: [Fastboot] [PATCH]IA64 kexec/kdump patch for INIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2006-09-11 at 14:56, Keith Owens wrote:
> Takao Indoh (on Thu, 07 Sep 2006 23:48:51 +0900) wrote:
> >On Thu, 7 Sep 2006 21:01:17 +0800, "Yu, Luming" wrote:
> >
> >>>>Did  saved Os gp in SAL OS state  somehow get overridden before 
> >>>>ia64_set_kernel_registers prior to invocation of
> ia64_init_handler?
> >>>>
> >>>>I assume the following code (in ia64_set_kernel_registers ) 
> >>>should restore 
> >>>>correct GP value.
> >>>>
> >>>>ia64_set_kernel_registers:
> >>>>    ...
> >>>>        ;;
> >>>>        ld8 r1=[temp4]          // OS GP from SAL OS state
> >>>
> >>>Yes, but this gp value is physical address.
> >>>In the next line, gp is changed to virtual address.
> >>>
> >>>DATA_PA_TO_VA(r1,temp1)
> >>>
> >>>This macro just sets region7 bit, so gp value becomes region7
> address.
> >>
> >>Ok, could you please confirm what is the value of r1 before
> >>DATA_PA_TO_VA(r1, temp1)?
> >>I guess we need to set r1 = __gp in ia64_set_kernel_registers.
> >>If not,  this is a bug.  Am I right?
> >
> >In the ia64_mca_init, the value of ia64_tpa(ia64_getreg(_IA64_REG_GP)
> >is registered as gp value. When cpu comes into the above code, r1 is
> set
> >to this value, I think. Therefore, r1 has physical address of __gp
> >before DATA_PA_TO_VA(r1, temp1). How do you think?
> >
> >I think you are right, I also think r1 has to be set to __gp before 
> >calling ia64_init_handler.
> 
> It already is set in mca_asm.S.  Remember that ia64_init_handler is by
> definition part of the kernel, it cannot be a module.  Therefore
> before
> entering ia64_init_handler, r1 must be set to what the kernel expects
> to be in r1.  The standard kernel's r1 is a region 7 address, not a
> region 5 address.  The kernel (including __gp) is compiled as region 5
> but relocated to region 7 during kernel load.
> 
> Is the kexec kernel running in region 5?  That may be where the
> confusion is coming from.
> 
Hi Keith,
	For 2.6 kernel, I think GP is a region 5 address when inside kernel.
The entire kernel image is resided in region 5 without relocate to
region 7. 
	Another issue I can see from calculate GP from physical address passed
from OS_INIT is,
	I am not quite sure though, if OS_INIT is happened during a module
execution, or happened when system is in user space, what GP value will
be passed from SAL/PAL? If the gp value is the physical address of the
modules 's gp, we can't set GP value according to that, because
ia64_init_handler is inside kernel.
	
	Kexec kernel used in kdump is usually exactly the same kernel with the
host kernel, except they are located in different physical address
ranges. The first kernel will never touch the RAM belongs to the crash
kernel at run time. The crash kernel will not touch the RAM belongs to
the first kernel unless you read it via /proc/vmcore.

Thanks 	
Zou Nan hai 

> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64"
> in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Sparc Linux]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux x86_64]     [Linux for Ham Radio]

  Powered by Linux