> -----Original Message----- > From: Horms [mailto:horms@xxxxxxxxxxxx] > 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 - 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
|