[PATCH 2/2] ARM: don't depend on vmalloc_start
Masayuki Igawa
igawa at mxs.nes.nec.co.jp
Thu Nov 4 22:18:42 EDT 2010
Hi Mika,
Thank you for your patches.
Some comments are below.
From: Mika Westerberg <ext-mika.1.westerberg at nokia.com>
Subject: [PATCH 2/2] ARM: don't depend on vmalloc_start
Date: Thu, 4 Nov 2010 10:15:17 +0200
> In ARM, modules are placed in vmalloc'ed area right above user stack and the
> rest of the vmalloc area is somewhere after high_memory (this can be different
> on different platforms). Since this value is not stored in vmcoreinfo, we have
> no means to find out the correct value for vmalloc_start.
>
> So we assume that all V->P translations are within the kernel direct mapped
> memory and use translation tables only when '--vtop' option is passed.
>
> Signed-off-by: Mika Westerberg <ext-mika.1.westerberg at nokia.com>
> ---
> arm.c | 40 +++++++++++++++++++---------------------
> 1 files changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/arm.c b/arm.c
> index 3ea450a..6469f03 100644
> --- a/arm.c
> +++ b/arm.c
> @@ -86,6 +86,9 @@ get_machdep_info_arm(void)
> info->kernel_start = SYMBOL(_stext);
> info->section_size_bits = _SECTION_SIZE_BITS;
>
> + DEBUG_MSG("page_offset : %lx\n", info->page_offset);
> + DEBUG_MSG("kernel_start : %lx\n", info->kernel_start);
> +
> /*
> * For the compatibility, makedumpfile should run without the symbol
> * vmlist and the offset of vm_struct.addr if they are not necessary.
> @@ -95,31 +98,28 @@ get_machdep_info_arm(void)
> return TRUE;
> }
>
> + /*
> + * In ARM the VMALLOC_START can be redefined per platform and we have no
> + * means to read that from the vmcore (there is currently no vmcoreinfo
> + * which specifies that), so we are not going to use vmalloc_start for
> + * anything.
> + */
> if (!readmem(VADDR, SYMBOL(vmlist), &vmlist, sizeof(vmlist))) {
> ERRMSG("Can't get vmlist.\n");
> - return FALSE;
> + return TRUE;
> }
> if (!readmem(VADDR, vmlist + OFFSET(vm_struct.addr), &vmalloc_start,
> sizeof(vmalloc_start))) {
> ERRMSG("Can't get vmalloc_start.\n");
> - return FALSE;
> + return TRUE;
> }
I think this code can be removed.
Because this code is easy to misunderstand for users and
there are no means to check now.
>
> info->vmalloc_start = vmalloc_start;
> -
> - DEBUG_MSG("page_offset : %lx\n", info->page_offset);
> - DEBUG_MSG("kernel_start : %lx\n", info->kernel_start);
> DEBUG_MSG("vmalloc_start: %lx\n", vmalloc_start);
These codes too?
There is no need 'info->vmalloc_start' by removing is_vmalloc_addr_arm() in ARM now.
>
> return TRUE;
> }
>
> -static int
> -is_vmalloc_addr_arm(unsigned long vaddr)
> -{
> - return (info->vmalloc_start && vaddr >= info->vmalloc_start);
> -}
> -
> /*
> * vtop_arm() - translate arbitrary virtual address to physical
> * @vaddr: virtual address to translate
> @@ -184,17 +184,15 @@ vtop_arm(unsigned long vaddr)
> unsigned long long
> vaddr_to_paddr_arm(unsigned long vaddr)
> {
> - unsigned long long paddr = vaddr_to_paddr_general(vaddr);
> -
> - if (paddr != NOT_PADDR)
> - return paddr;
> -
> - if (is_vmalloc_addr_arm(vaddr))
> - paddr = vtop_arm(vaddr);
> - else
> - paddr = __pa(vaddr);
> + /*
> + * Only use translation tables when user has explicitly requested us to
> + * perform translation for a given address. Otherwise we assume that the
> + * translation is done within the kernel direct mapped region.
> + */
> + if (info->vaddr_for_vtop == vaddr)
> + return vtop_arm(vaddr);
>
> - return paddr;
> + return __pa(vaddr);
> }
Why do you use vtop tranlation only when '--vtop' option is passed?
I think if you don't need vtop translation, vtop_arm() can be removed
and vaddr_to_paddr_arm() can be like below.
===
unsigned long long
vaddr_to_paddr_arm(unsigned long vaddr)
{
unsigned long long paddr;
paddr = __pa(vaddr);
if (info->vaddr_for_vtop == vaddr)
MSG(" VADDR : %08lx => PADDR : %08lx\n", vaddr, paddr);
return paddr;
}
===
Thanks.
-- Masayuki Igawa
>
> #endif /* __arm__ */
> --
> 1.5.6.5
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3578 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20101105/295bcfae/attachment.p7s>
More information about the kexec
mailing list