ia64 kexec: control_page

From: Horms <horms_at_verge.net.au>
Date: 2006-08-24 17:39:39
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

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.

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

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
Received on Thu Aug 24 17:45:09 2006

This archive was generated by hypermail 2.1.8 : 2006-08-24 17:45:23 EST