[RFC PATCH] ARM: kexec: Assemble relocate code in ARM mode

[Dave Martin]

On Fri, Oct 18, 2013 at 10:29:41PM +0300, Taras Kondratiuk wrote:
> On 10/15/2013 06:24 PM, Dave Martin wrote:
> > On Thu, Oct 10, 2013 at 11:36:08PM +0300, Taras Kondratiuk wrote:
> >> I think it won't help, because here is no direct jump to this label.
> >> This code gets copied to a new page and jump is done to the beginning
> >> of that page.
> > 
> > Ah, right.
> > 
> > I think that the fncpy() function should work.  This is for the precise
> > purpsoe of copying a function body from one place to another, while
> > reatining the Thumb bit.
> > 
> > I have to disappear early to today, but I'll try and follow up.
> > 
> > Currently, I have the following, but I've not been able to test it yet.
> > If you'd like to give it a try, that would be much appreciated.
> 
> I've tried the patch on ARM ISA and looks like the code does what

Thanks for giving it a try.

> it should, but the reloaded kernel crashes somewhere at early stages.
> Without this patch it boots fine on ARM. Next week I will try to look
> what is going on.

Hmmm, that's a bit strange.  You're saying that the new kernel gets
loaded and started OK, but crashes during boot?

If relocate_new_kernel() was failing, I would not expect the new
kernel to boot at all, unless part of the kernel doesn't get relocated,
or something like that.

> > 
> > From 94925667e650202e1baf74e1ff223671d316401d Mon Sep 17 00:00:00 2001
> > From: Dave Martin <Dave.Martin at arm.com>
> > Date: Tue, 15 Oct 2013 11:48:46 +0100
> > Subject: [PATCH] ARM: kexec: Use the right ISA for relocate_new_kernel
> > 
> > Copying a function with memcpy() and then trying to execute the
> > result isn't portable to Thumb.
> > 
> > This patch modifies the kexec soft restart code to copy its
> > assembler trampoline relocate_new_kernel() using fncpy() instead,
> > so that relocate_new_kernel can be in the same ISA as the rest of
> > the kernel without problems.
> > 
> > Signed-off-by: Dave Martin <Dave.Martin at arm.com>
> > ---
> >  arch/arm/kernel/machine_kexec.c   |   20 +++++++++-----------
> >  arch/arm/kernel/relocate_kernel.S |    7 ++++---
> >  2 files changed, 13 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> > index 57221e3..ce135b3 100644
> > --- a/arch/arm/kernel/machine_kexec.c
> > +++ b/arch/arm/kernel/machine_kexec.c
> > @@ -11,6 +11,7 @@
> >  #include <linux/memblock.h>
> >  #include <asm/pgtable.h>
> >  #include <linux/of_fdt.h>
> > +#include <asm/fncpy.h>
> >  #include <asm/pgalloc.h>
> >  #include <asm/mmu_context.h>
> >  #include <asm/cacheflush.h>
> > @@ -18,7 +19,7 @@
> >  #include <asm/smp_plat.h>
> >  #include <asm/system_misc.h>
> >  
> > -extern const unsigned char relocate_new_kernel[];
> > +extern char relocate_new_kernel;
> 
> Shouldn't it be a function pointer?
> extern void relocate_new_kernel(void);

Actually, it could be.

I was forgetting that fncpy was implemented as a macro, allowing
it to be more forgiving about argument types.

Casting a function pointer type to a non-function pointer type is
illegal in C, but fncpy dodges that problem by hiding the cast
inside an asm so that the compiler can't try to do clever optimisations
that might break things.

Cheers
---Dave