ia64 kexec: control_page

ia64 kexec: control_page

[Horms]

Hi Nanhai,

As I've mentioned several times in the past I am working on porting
kexec to Xen.  And I am once again casting my eye on porting the ia64
portion.  To this end, I would like to discuss the control_page a
little.

Its currently defined to be 8k + 8k + 4k = 20k bytes long, and assembly
in arch/ia64/kernel/relocate_kernel.S is copied into it.  The resulting
contents looks a bit like this, as per the most recent patch you posted
last week.

  0x0000: relocate_kernel (code)
  ...
  0x0360: memory_stack    (data, 8k)
  ...
  0x2360  register_stack  (data, 8k)
  ...
  0x4360  kexec_fake_sal_rendez (code)
  ...
  0x4640 ia64_dump_cpu_regs (code)
  ...
  0x48c0  end

The problem that I am facing is that in Xen this region, though
contiguous in the kernel, is not actually physically contiguous if the
page size is less than 20k.  As 4k pages don't work for ia64 xen (so I
am lead to believe), this is basically the 16k page case, where the last
0x0360 bytes of the register_stack will be on a second page.

The immediate problem that I have is that I need to pass down the
address of kexec_fake_sal_rendez (and probably ia64_dump_cpu_regs) to
the hypervisor so it can call that code.  This is pretty easy to work
around by just working out which page taking things from there -
fortunately they do not cross a page boundary, even for the 4k case.

One thing that I tried that would alleviate this problem is to reduce
both memory_stack and register_stack to 4k each.  This seems to work on
my Tiger4, but I am not sure what the sizing issues around these areas
are.  Could you elaborate?

Thinking a bit more, it seems that a different layout could help things
even more.  For instance, if all the code was moved to the front, it
should easily fit on one page, even for the 4k case.  Well, that is
unless you are planning to write a lot more assembly.  In which case
additional code pages could be added.  The data areas could be a
separate page (or pages), passed in as arguments to relocate_kernel.

This would probably make the Xen port cleaner (I say probably, because I
haven't finished the port and thus there may be issues I haven't thought
of) without greatly impacting on the linux code.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

RE: ia64 kexec: control_page

[Zou, Nanhai]

> -----Original Message-----
> From: Horms [mailto:horms@verge.net.au]
> Sent: 2006Äê8ÔÂ24ÈÕ 15:40
> To: Zou, Nanhai
> Cc: fastboot; Linux-IA64; Magnus Damm
> Subject: ia64 kexec: control_page
> 
> Hi Nanhai,
> 
> As I've mentioned several times in the past I am working on porting
> kexec to Xen.  And I am once again casting my eye on porting the ia64
> portion.  To this end, I would like to discuss the control_page a
> little.
> 
> Its currently defined to be 8k + 8k + 4k = 20k bytes long, and assembly
> in arch/ia64/kernel/relocate_kernel.S is copied into it.  The resulting
> contents looks a bit like this, as per the most recent patch you posted
> last week.
> 
>   0x0000: relocate_kernel (code)
>   ...
>   0x0360: memory_stack    (data, 8k)
>   ...
>   0x2360  register_stack  (data, 8k)
>   ...
>   0x4360  kexec_fake_sal_rendez (code)
>   ...
>   0x4640 ia64_dump_cpu_regs (code)
>   ...
>   0x48c0  end
> 
> The problem that I am facing is that in Xen this region, though
> contiguous in the kernel, is not actually physically contiguous if the
> page size is less than 20k.  As 4k pages don't work for ia64 xen (so I

Hi Horms,
	4k stacks should work in practice. 
However I defined the 8k stack and backing store sizes according to 
SAL spec 3.2.4
"Firmware to Operation System Hand-Off state"

The fake_sal_rendz related code is from Aziz for kernel without CONFIG_CPU _HOTPLUG enabled, 
However it is currently not working, still need fix from Aziz. 

My personal opinion is that we don't need the fake randz code, since they will not be executed at the time of kdump. 
While at the time of kexec, we can use the CPU hotplug code to put CPUS back to SAL rendz state.

Thanks
Zou Nan hai