On Wed, 2019-07-17 at 17:45 +, Vineet Gupta wrote:
> On 7/17/19 8:09 AM, Eugeniy Paltsev wrote:
> > > > +/* Halt system on fatal error to make debug easier */
> > > > +#define arc_jl_fatal(format...)
> > > > \
> > > > +({
On 7/17/19 8:09 AM, Eugeniy Paltsev wrote:
>>> +/* Halt system on fatal error to make debug easier */
>>> +#define arc_jl_fatal(format...)
>>> \
>>> +({ \
>>> + pr_err(JUMPLABEL_ERR format)
Hi Vineet,
I'm finally back, so see my comments below.
On Tue, 2019-06-18 at 16:16 +, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
> > Implement jump label patching for ARC. Jump labels provide
> > an interface to generate dynamic branches using
> > self-modifying code.
> >
On 6/18/19 9:16 AM, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
>> Implement jump label patching for ARC. Jump labels provide
>> an interface to generate dynamic branches using
>> self-modifying code.
>>
>> This allows us to implement conditional branches where
>> changing bran
On 6/18/19 9:16 AM, Vineet Gupta wrote:
> On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
>> Implement jump label patching for ARC. Jump labels provide
>> an interface to generate dynamic branches using
>> self-modifying code.
>>
>> This allows us to implement conditional branches where
>> changing bran
> On Jun 21, 2019, at 5:12 AM, Peter Zijlstra wrote:
>
> On Fri, Jun 21, 2019 at 02:09:23PM +0200, Peter Zijlstra wrote:
>
>> --- /dev/null
>> +++ b/arch/x86/include/asm/jump_label_asm.h
>> @@ -0,0 +1,44 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _ASM_X86_JUMP_LABEL_ASM_H
>> +#def
Baron
> ; Paolo Bonzini
> ; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev
>
> Subject: Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching
[snip]
> Insn encoding is always middl eendina - irrespective of endianness.
Apparently only in little-endian mode instruc
On Fri, Jun 21, 2019 at 02:09:23PM +0200, Peter Zijlstra wrote:
> --- /dev/null
> +++ b/arch/x86/include/asm/jump_label_asm.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_X86_JUMP_LABEL_ASM_H
> +#define _ASM_X86_JUMP_LABEL_ASM_H
> +
> +#include
> +#include
> +
> +
On Thu, Jun 20, 2019 at 11:22:56PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 20, 2019 at 11:48:17AM -0700, Vineet Gupta wrote:
> > I do worry about the occasional alignment induced extra NOP_S instruction
> > (2 byte)
> > but there doesn't seem to be an easy solution. Heck if we could use the
>
On Thu, Jun 20, 2019 at 06:34:55PM +, Eugeniy Paltsev wrote:
> On Thu, 2019-06-20 at 09:01 +0200, Peter Zijlstra wrote:
> > In particular we do not need the alignment.
> >
> > So what the x86 code does is:
> >
> > - overwrite the first byte of the instruction with a single byte trap
> >
On Thu, Jun 20, 2019 at 11:48:17AM -0700, Vineet Gupta wrote:
> On 6/20/19 12:01 AM, Peter Zijlstra wrote:
>
> >
> > In particular we do not need the alignment.
> >
> > So what the x86 code does is:
> >
> > - overwrite the first byte of the instruction with a single byte trap
> >instructio
On Thu, Jun 20, 2019 at 06:34:29PM +, Eugeniy Paltsev wrote:
> On Wed, 2019-06-19 at 10:12 +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 04:16:20PM +, Vineet Gupta wrote:
> > I'm assuming you've looked at what x86 currently does and found
> > something like that doesn't work for
On 6/20/19 12:52 AM, Peter Zijlstra wrote:
>
> With everything little endian, everything seems just fine. If you load
> the first 2 byte at offset 0, you get the first 2 bytes of the
> instruction.
It has to do with the instruction encoding scheme and what part of instruction
has
the major opcod
On 6/20/19 12:01 AM, Peter Zijlstra wrote:
>
> In particular we do not need the alignment.
>
> So what the x86 code does is:
>
> - overwrite the first byte of the instruction with a single byte trap
>instruction
>
> - machine wide IPI which synchronizes I$
>
> At this point, any CPU tha
Hi Peter,
On Thu, 2019-06-20 at 09:01 +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> > On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> > > I'm assuming you've looked at what x86 currently does and found
> > > something like that doesn't work for ARC?
> >
Hi Peter,
On Wed, 2019-06-19 at 10:12 +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 04:16:20PM +, Vineet Gupta wrote:
>
> > > +/*
> > > + * To make atomic update of patched instruction available we need to
> > > guarantee
> > > + * that this instruction doesn't cross L1 cache line b
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> >>> +static inline u32 arc_gen_nop(void)
> >>> +{
> >>> + /* 1x 32bit NOP in middle endian */
> > I dare not ask...
>
> :-) The public PRM is being worked on for *real* so this will be reme
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> So we ensure a patched instruction never crosses a
> cache line - using .balign 4. This causes a slight mis-optimization that all
> patched instruction locations are forced to be 4 bytes aligned while ISA
> allows
> code to be 2 byte
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> FWIW I tried to avoid all of this by using the 2 byte NOP_S and B_S variants
> which
> ensures we can never straddle cache line so the alignment issue goes away.
> There's
> a nice code size reduction too - see [1] . But I get build
On Wed, Jun 19, 2019 at 11:55:41PM +, Vineet Gupta wrote:
> On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> > I'm assuming you've looked at what x86 currently does and found
> > something like that doesn't work for ARC?
>
> Just looked at x86 code and it seems similar
I think you missed a bit.
On 6/19/19 1:12 AM, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 04:16:20PM +, Vineet Gupta wrote:
>
>>> +/*
>>> + * To make atomic update of patched instruction available we need to
>>> guarantee
>>> + * that this instruction doesn't cross L1 cache line boundary.
>>> + *
> Oh urgh. Is that
On Tue, Jun 18, 2019 at 04:16:20PM +, Vineet Gupta wrote:
> > +/*
> > + * To make atomic update of patched instruction available we need to
> > guarantee
> > + * that this instruction doesn't cross L1 cache line boundary.
> > + *
Oh urgh. Is that the only way ARC can do text patching? We've
On 6/14/19 9:41 AM, Eugeniy Paltsev wrote:
> Implement jump label patching for ARC. Jump labels provide
> an interface to generate dynamic branches using
> self-modifying code.
>
> This allows us to implement conditional branches where
> changing branch direction is expensive but branch selection
>
Implement jump label patching for ARC. Jump labels provide
an interface to generate dynamic branches using
self-modifying code.
This allows us to implement conditional branches where
changing branch direction is expensive but branch selection
is basically 'free'
This implementation uses 32-bit NO
24 matches
Mail list logo
