From: Michael Ellerman <mpe@ellerman•id.au>
To: Gabriel Paubert <paubert@iram•es>
Cc: Anshuman Khandual <khandual@linux•vnet.ibm.com>,
linuxppc-dev@ozlabs•org, mikey@neuling•org
Subject: Re: [RFC 5/8] powerpc/slb: Add documentation to runtime patching of SLB encoding
Date: Wed, 22 Jul 2015 19:01:23 +1000 [thread overview]
Message-ID: <1437555683.27712.4.camel@ellerman.id.au> (raw)
In-Reply-To: <20150722055740.GA20532@visitor2.iram.es>
On Wed, 2015-07-22 at 07:57 +0200, Gabriel Paubert wrote:
> On Wed, Jul 22, 2015 at 03:51:03PM +1000, Michael Ellerman wrote:
> > On Tue, 2015-07-21 at 12:28 +0530, Anshuman Khandual wrote:
> > > From: "khandual@linux•vnet.ibm.com" <khandual@linux•vnet.ibm.com>
> > >
> > > This patch adds some documentation to 'patch_slb_encoding' function
> > > explaining about how it clears the existing immediate value in the
> > > given instruction and inserts a new one there.
> > >
> > > diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> > > index dcba4c2..8083a9e 100644
> > > --- a/arch/powerpc/mm/slb.c
> > > +++ b/arch/powerpc/mm/slb.c
> > > @@ -278,7 +278,13 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> > > static inline void patch_slb_encoding(unsigned int *insn_addr,
> > > unsigned int immed)
> > > {
> > > - int insn = (*insn_addr & 0xffff0000) | immed;
> > > + /*
> > > + * Currently this patches only "li" and "cmpldi"
> > > + * instructions with an immediate value. Here it
> > > + * just clears the existing immediate value from
> > > + * the instruction and inserts a new one there.
> > > + */
> > > + unsigned int insn = (*insn_addr & 0xffff0000) | immed;
> > > patch_instruction(insn_addr, insn);
> > > }
> >
> >
> > How about:
> >
> > /*
> > * This function patches either an li or a cmpldi instruction with
> > * a new immediate value. This relies on the fact that both li
> > * (which is actually ori) and cmpldi both take a 16-bit immediate
>
> Hmm, li is actually encoded as addi with r0 as source register...
Correct.
> > * value, and it is situated in the same location in the instruction,
> > * ie. bits 0-15.
>
> In PPC documentation, it's rather bits 16-31 (big endian bit order).
> Or say lower half which is endian agnostic.
Yeah, but who reads the PPC documentation ;)
In the kernel we almost always use the sane bit numbering, so I'd use that, but
maybe "low 16-bits" will avoid confusion.
cheers
next prev parent reply other threads:[~2015-07-22 9:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-21 6:58 [RFC 1/8] powerpc/slb: Remove a duplicate extern variable Anshuman Khandual
2015-07-21 6:58 ` [RFC 2/8] powerpc/slb: Rename all the 'entry' occurrences to 'slot' Anshuman Khandual
2015-07-21 9:46 ` [RFC, " Michael Ellerman
2015-07-21 11:23 ` [RFC,2/8] " Anshuman Khandual
2015-07-21 6:58 ` [RFC 3/8] powerpc/slb: Define macros for the bolted slots Anshuman Khandual
2015-07-22 9:32 ` Michael Ellerman
2015-07-21 6:58 ` [RFC 4/8] powerpc/slb: Add some helper functions to improve modularization Anshuman Khandual
2015-07-22 9:19 ` Michael Ellerman
2015-07-21 6:58 ` [RFC 5/8] powerpc/slb: Add documentation to runtime patching of SLB encoding Anshuman Khandual
2015-07-22 5:51 ` Michael Ellerman
2015-07-22 5:57 ` Gabriel Paubert
2015-07-22 9:01 ` Michael Ellerman [this message]
2015-07-22 12:17 ` Segher Boessenkool
2015-07-21 6:58 ` [RFC 6/8] powerpc/prom: Simplify the logic while fetching SLB size Anshuman Khandual
2015-07-21 10:21 ` [RFC, " Michael Ellerman
2015-07-21 11:24 ` Anshuman Khandual
2015-07-21 6:58 ` [RFC 7/8] powerpc/xmon: Drop 'valid' from the condition inside 'dump_segments' Anshuman Khandual
2015-07-21 10:00 ` [RFC, " Michael Ellerman
2015-07-21 11:45 ` Anshuman Khandual
2015-07-22 4:52 ` Michael Ellerman
2015-07-21 6:58 ` [RFC 8/8] powerpc/xmon: Add some more elements to the existing PACA dump list Anshuman Khandual
2015-07-21 10:08 ` [RFC, " Michael Ellerman
2015-07-21 11:48 ` Anshuman Khandual
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=1437555683.27712.4.camel@ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=khandual@linux$(echo .)vnet.ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=mikey@neuling$(echo .)org \
--cc=paubert@iram$(echo .)es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox