|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-ia64-devel] [rfc 04/15] Kdump: Save dom0_mm_pgd_mfn in vmcore on ia64
Get rid of dummy_efi_set_virtual_address_map
In ia64's EFI a runtime method efi_set_virtual_address_map is provided to
map EFI calls into physical space. Before calling this EFI calls can only
be made in physical mode. Afterwards they can only be made in virtual mode.
There is a restriction that efi_set_virtual_address_map may only be called
once and will fail if it is called a second time. This is a problem for
kexec as the init code will try and call efi_set_virtual_address_map each
time that kexec is performed - that is on each soft-boot.
dummy_set_virtual_address_map is a method of avoiding this problem by
having purgatory patch efi_set_virtual_address_map with a function that
does nothing. While the original author of this code is quite fond of it, I
am not because basically it requires purgatory to have knowledge of the
pa/vm conversion that would not other wise be at all neccessary. Morover,
purgatory is a very fragile, very difficult to debug section of code that
realy ought not have anything in there that isn't absolutely neccessary.
One solution would be to do the patching in the kernel just before going
into purgatory. This should have much the same scemantics of
dummy_set_virtual_address_map without the drawbacks of cruft in purgatory -
actually, its a pretty good idea now that I think about it.
This solution just inspects EFI, and works out if its already mapped or
not. If not, it maps it. If so, it uses the existing map. This solution has
the disadvantage that it requires the second kernel to be patched. People
tell me that they want to be able to run old kernels as their second
kernels. Frankly I doubt it would work on ia64. And even if it would, given
that kexec is new technology on ia64, which only very recently started
working at all, I doub't people who are deploying it are deploying it with
ancient unpatchable kernels. But I could be wrong.
This patch has a companion patch to kexec-tools which removes the patching
code.
Note that all of thes solutions discussed so far do not allow for the pa/vm
scheme to change between reboots. This is a problem for linux->xen and
xen->linux transistions as PAGE_OFFSET is different. In other words, they
won't work. This is a particular problem in the context of kdump for xen,
which uses linux as a second kernel. the phys_efi patches I have are a
workaround for this, but I've been told that they won't fly on several
platforms - i think they might only work on intel tiger machines.
I think that a good way forward on this problem is to extend the patch
below to map the EFI to its old position if possible. And blow up if it
isn't. This should basically mean that moving forward xen and linux will
work with each other. And other combinations will need to be tested and
patched. As for the lets not patch the second kernel camp - good luck.
Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
Index: xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c
===================================================================
--- xen-unstable.hg.orig/xen/arch/ia64/linux-xen/efi.c 2007-07-26
17:50:53.000000000 +0900
+++ xen-unstable.hg/xen/arch/ia64/linux-xen/efi.c 2007-07-28
08:39:11.000000000 +0900
@@ -663,14 +663,27 @@ efi_enter_virtual_mode (void)
}
}
- status = efi_call_phys(__va(runtime->set_virtual_address_map),
- ia64_boot_param->efi_memmap_size,
- efi_desc_size,
ia64_boot_param->efi_memdesc_version,
- ia64_boot_param->efi_memmap);
- if (status != EFI_SUCCESS) {
- printk(KERN_WARNING "warning: unable to switch EFI into virtual
mode "
- "(status=%lu)\n", status);
- return;
+ if ((unsigned long)__va(runtime->set_virtual_address_map) ==
+ runtime->set_virtual_address_map) {
+ printk(KERN_WARNING "warning: EFI is already mapped "
+ "in the right place\n");
+ }
+ else if (runtime->set_virtual_address_map & (0xfUL << 60)) {
+ printk(KERN_WARNING "warning: EFI is already mapped "
+ "in the wrong place\n");
+ return;
+ }
+ else {
+ status = efi_call_phys(__va(runtime->set_virtual_address_map),
+ ia64_boot_param->efi_memmap_size,
+ efi_desc_size,
+ ia64_boot_param->efi_memdesc_version,
+ ia64_boot_param->efi_memmap);
+ if (status != EFI_SUCCESS) {
+ printk(KERN_WARNING "warning: unable to switch EFI "
+ "into virtual mode (status=%lu)\n", status);
+ return;
+ }
}
/*
Index: xen-unstable.hg/xen/arch/ia64/xen/machine_kexec.c
===================================================================
--- xen-unstable.hg.orig/xen/arch/ia64/xen/machine_kexec.c 2007-07-26
17:50:53.000000000 +0900
+++ xen-unstable.hg/xen/arch/ia64/xen/machine_kexec.c 2007-07-26
18:18:24.000000000 +0900
@@ -44,27 +44,6 @@ void machine_kexec_unload(int type, int
{
}
-/*
- * boot_param is used inside purgatory and purgatory runs
- * in physical mode, so translate the addresses that purgatory
- * accesses from virtual to physical.
- */
-static unsigned long machine_kexec_prepare_boot_param (void)
-{
- efi_system_table_t *systab;
-
- systab = (efi_system_table_t *)__va(ia64_boot_param->efi_systab);
-
- if ((unsigned long)systab->runtime > PAGE_OFFSET) {
- systab->runtime->set_virtual_address_map =
- __pa(systab->runtime->set_virtual_address_map);
- systab->runtime = (efi_runtime_services_t *)
- __pa(systab->runtime);
- }
-
- return __pa(ia64_boot_param);
-}
-
static void ia64_machine_kexec(struct unw_frame_info *info, void *arg)
{
xen_kexec_image_t *image = arg;
@@ -102,7 +81,7 @@ static void ia64_machine_kexec(struct un
platform_kernel_launch_event();
rnk = (relocate_new_kernel_t)&code_addr;
(*rnk)(image->indirection_page, image->start_address,
- machine_kexec_prepare_boot_param(),
+ ia64_boot_param,
GRANULEROUNDDOWN((unsigned long) pal_vaddr), cpu_data_pa,
KERNEL_START, PAGE_OFFSET);
BUG();
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |