All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki Poulose <suzuki@in.ibm.com>
To: Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com>
Cc: Nathan Miller <nathanm2@us.ibm.com>,
	Josh Poimboeuf <jpoimboe@us.ibm.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Alan Modra <amodra@au1.ibm.com>,
	Scott Wood <scottwood@freescale.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
Date: Fri, 04 Nov 2011 14:06:28 +0530	[thread overview]
Message-ID: <4EB3A40C.1070802@in.ibm.com> (raw)
In-Reply-To: <1320276969.3309.3.camel@treble>

On 11/03/11 05:06, Josh Poimboeuf wrote:
> On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
>> The following patch implements the dynamic relocation processing for
>> PPC32 kernel. relocate() accepts the target virtual address and relocates
>>   the kernel image to the same.
>
> Hi Suzuki,
>
> Thanks for the patches.  I've been testing them on a 440-based card, and
> encountered TLB error exceptions because the BSS section wasn't getting
> properly cleared in early_init().

Thanks a lot for the testing.
>
> It turns out that some of the instructions which were modified in
> relocate() weren't then getting flushed out of the d-cache into memory.
> After that, early_init() executed the stale (non-modified) instructions
> for the BSS area.  Those instructions just accessed offset 0 instead of
> the actual BSS-related offsets.  That resulted in BSS not getting`
> zeroed.
>
> I was able to verify this on my 440 by comparing the d-cache and i-cache
> entries for the BSS-accessing instructions in early_init() using a
> RISCWatch.  As I suspected, the instructions in the d-cache showed the
> corrected offsets, but the i-cache showed the old, non-relocated
> offsets.
>
> To fix the issue, I wrote the following patch, applied on top of your
> patches.  Suggestions and comments are welcome.
>
>
>
>  From c88ae39da0c0352f411aca8d9636990a442d47da Mon Sep 17 00:00:00 2001
> From: Josh Poimboeuf<jpoimboe@linux.vnet.ibm.com>
> Date: Wed, 2 Nov 2011 16:41:24 -0500
> Subject: [PATCH] Flush relocated instructions from data cache
>
> After updating instructions with relocated addresses, flush them from
> the data cache and invalidate the icache line so we don't execute stale
> instructions.
>
> Signed-off-by: Josh Poimboeuf<jpoimboe@linux.vnet.ibm.com>
> ---
>   arch/powerpc/kernel/reloc_32.S |   11 ++++++++++-
>   1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/reloc_32.S
> b/arch/powerpc/kernel/reloc_32.S
> index 045d61e..a92857d 100644
> --- a/arch/powerpc/kernel/reloc_32.S
> +++ b/arch/powerpc/kernel/reloc_32.S
> @@ -137,6 +137,9 @@ get_type:
>   	lwz	r0, 8(r9)	/* r_addend */
>   	add	r0, r0, r3	/* final addend */
>   	stwx	r0, r4, r7	/* memory[r4+r7]) = (u32)r0 */
> +	dcbst	r4,r7		/* flush dcache line to memory */
> +	sync			/* wait for flush to complete */
> +	icbi	r4,r7		/* invalidate icache line */

Doing it this way has two drawbacks :

1) Placing it here in relocate would do the flushing for each and every update.
2) I would like to keep this code as generic as possible for the PPC32 code.

Could we move this to the place from relocate is called and flush the d-cache and
i-cache entirely ?

Thanks

Suzuki

  reply	other threads:[~2011-11-04  8:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-25 11:53 [PATCH v2 0/5] Kdump support for PPC440x Suzuki K. Poulose
2011-10-25 11:53 ` [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel Suzuki K. Poulose
2011-11-02 23:36   ` Josh Poimboeuf
2011-11-04  8:36     ` Suzuki Poulose [this message]
2011-11-07 15:13       ` Josh Poimboeuf
2011-11-07 15:26         ` David Laight
2011-11-08  7:11         ` Suzuki Poulose
2011-11-08 16:19           ` Josh Poimboeuf
2011-11-09  6:33             ` Suzuki Poulose
2011-11-09  8:42               ` Suzuki Poulose
2011-11-09 14:53               ` Josh Poimboeuf
2011-11-10  2:31                 ` Suzuki Poulose
2011-11-10  9:15                   ` David Laight
2011-11-10 21:44                   ` Josh Poimboeuf
2011-11-11  4:11                   ` Benjamin Herrenschmidt
2011-10-25 11:54 ` [PATCH v2 2/5] [ppc] Define virtual-physical translations for PIE relocations Suzuki K. Poulose
2011-10-25 11:54 ` [PATCH v2 3/5] [44x] Enable CONFIG_RELOCATABLE for PPC44x Suzuki K. Poulose
2011-10-25 11:54 ` [PATCH v2 4/5] [44x] Enable CRASH_DUMP for 440x Suzuki K. Poulose
2011-10-25 11:54 ` [PATCH v2 5/5] [boot] Change the load address for the wrapper to fit the kernel Suzuki K. Poulose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EB3A40C.1070802@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=amodra@au1.ibm.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=jpoimboe@linux.vnet.ibm.com \
    --cc=jpoimboe@us.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nathanm2@us.ibm.com \
    --cc=paulus@samba.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.