public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Zou Nan hai <nanhai.zou@intel.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fastboot] [PATCH]IA64 kexec/kdump patch for INIT
Date: Mon, 11 Sep 2006 06:12:13 +0000	[thread overview]
Message-ID: <1157955133.2594.16.camel@linux-znh> (raw)
In-Reply-To: <82C6D21B8B7A9Cindou.takao@jp.fujitsu.com>

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  parent reply	other threads:[~2006-09-11  6:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-07  1:18 [Fastboot] [PATCH]IA64 kexec/kdump patch for INIT Takao Indoh
2006-09-07  1:32 ` Zou, Nanhai
2006-09-07  3:21 ` Takao Indoh
2006-09-07  8:45 ` Zou, Nanhai
2006-09-07  8:48 ` Yu Luming
2006-09-07  9:08 ` Andreas Schwab
2006-09-07  9:17 ` Takao Indoh
2006-09-07 13:01 ` Yu, Luming
2006-09-07 14:48 ` Takao Indoh
2006-09-07 16:38 ` Luck, Tony
2006-09-07 16:44 ` Andreas Schwab
2006-09-07 17:03 ` Luck, Tony
2006-09-08  1:20 ` Zou, Nanhai
2006-09-11  6:12 ` Zou Nan hai [this message]
2006-09-11  6:56 ` Keith Owens
2006-09-11 16:18 ` Luck, Tony
2006-09-13  2:27 ` Takao Indoh
2006-09-13  7:10 ` Keith Owens
2006-09-13  7:58 ` Zou, Nanhai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1157955133.2594.16.camel@linux-znh \
    --to=nanhai.zou@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox