All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Aleksandar Rikalo" <arikalo@gmail.com>,
	linux-riscv@lists.infradead.org,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Christoph Müllner" <christoph.muellner@vrull.eu>,
	linux-kernel@vger.kernel.org,
	"Djordje Todorovic" <djordje.todorovic@htecgroup.com>
Subject: Re: [PATCH v3] riscv: Fix the PAUSE Opcode for MIPS P8700.
Date: Thu, 30 Jan 2025 16:59:16 -0800	[thread overview]
Message-ID: <Z5wgZHnvu9EeE4xq@ghost> (raw)
In-Reply-To: <20250131-unknotted-yoga-bccacad0c6d3@spud>

On Fri, Jan 31, 2025 at 12:43:12AM +0000, Conor Dooley wrote:
> On Thu, Jan 30, 2025 at 02:58:49PM -0800, Charlie Jenkins wrote:
> > On Wed, Jan 29, 2025 at 04:19:58PM +0000, Conor Dooley wrote:
> > > On Wed, Jan 29, 2025 at 02:17:03PM +0100, Aleksandar Rikalo wrote:
> > > > From: Djordje Todorovic <djordje.todorovic@htecgroup.com>
> > > > 
> > > > The riscv MIPS P8700 uses a different opcode for PAUSE.
> > > > It is a ‘hint’ encoding of the SLLI instruction, with rd=0, rs1=0 and
> > > > imm=5. It will behave as a NOP instruction if no additional behavior
> > > > beyond that of SLLI is implemented.
> > > 
> > > You say p8700, but the erratum will be applied on all systems that are
> > > identified as using a mips cpu. Why's that?
> > > 
> > > > +void mips_errata_patch_func(struct alt_entry *begin,
> > > > +					     struct alt_entry *end,
> > > > +					     unsigned long archid,
> > > > +					     unsigned long impid,
> > > > +					     unsigned int stage)
> > > > +{
> > > > +	struct alt_entry *alt;
> > > > +
> > > > +	BUILD_BUG_ON(ERRATA_MIPS_NUMBER >= RISCV_VENDOR_EXT_ALTERNATIVES_BASE);
> > > > +
> > > > +	if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
> > > > +		return;
> > > > +
> > > > +	for (alt = begin; alt < end; alt++) {
> > > > +		if (alt->vendor_id != MIPS_VENDOR_ID)
> > > > +			continue;
> > > > +
> > > > +		if (alt->patch_id >= ERRATA_MIPS_NUMBER) {
> > > > +			WARN(1, "MIPS errata id:%d not in kernel errata list\n",
> > > > +			     alt->patch_id);
> > > > +			continue;
> > > > +		}
> > > > +
> > > > +		mutex_lock(&text_mutex);
> > > > +		patch_text_nosync(ALT_OLD_PTR(alt), ALT_ALT_PTR(alt), alt->alt_len);
> > > > +		mutex_unlock(&text_mutex);
> > > > +	}
> > > > +}
> > > 
> > > > diff --git a/tools/arch/riscv/include/asm/vdso/processor.h b/tools/arch/riscv/include/asm/vdso/processor.h
> > > > index 662aca039848..880f26a24f69 100644
> > > > --- a/tools/arch/riscv/include/asm/vdso/processor.h
> > > > +++ b/tools/arch/riscv/include/asm/vdso/processor.h
> > > > @@ -14,7 +14,10 @@ static inline void cpu_relax(void)
> > > >  	__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
> > > >  #endif
> > > >  
> > > > -#ifdef CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
> > > > +#ifdef CONFIG_ERRATA_MIPS_P8700_PAUSE_OPCODE
> > > > +    /* MIPS P8700 pause opcode */
> > > > +    __asm__ __volatile__ (".4byte 0x00501013");
> > > > +#elif CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
> > > >  	/*
> > > >  	 * Reduce instruction retirement.
> > > >  	 * This assumes the PC changes.
> > > 
> > > What about when the erratum is enabled and the toolchain supports
> > > Zihintpause?
> > 
> > So the other way to do this is having an hwprobe call to check if the
> > currently running processor is effected by this. However I was concerned
> > about the performance penalty of calling hwprobe here in the previous
> > version so I had suggested to use a flag instead so there is not the
> > penalty on other architectures. This does make it invalid to enable
> > this errata in the defconfig. This is a precedent for how we want to
> > handle errata in tools.
> 
> Gonna have to be marked non-portable then, if enabling it results in
> tools that might malfunction on other platforms.
> 
> > > Why don't you use the same implementation as the !tools
> > > copy of the header? (I'm not sure why they're different in the first
> > > place).
> > 
> > It is different because the headers in tools are userspace so it doesn't
> > make sense to have alternatives.
> 
> I assume that's an answer to the first part, and not the bit in
> brackets since the "first place" difference is about using the .4byte
> versus having an ifdef/else and you're talking about alternatives.
> That looks to have been some sort of sync issue or oversight in
> 6da111574baff, no?

Yeah it was a response to the first part.

As for the second part, yes it look it was a syncing issue.

- Charlie


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Aleksandar Rikalo" <arikalo@gmail.com>,
	linux-riscv@lists.infradead.org,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Christoph Müllner" <christoph.muellner@vrull.eu>,
	linux-kernel@vger.kernel.org,
	"Djordje Todorovic" <djordje.todorovic@htecgroup.com>
Subject: Re: [PATCH v3] riscv: Fix the PAUSE Opcode for MIPS P8700.
Date: Thu, 30 Jan 2025 16:59:16 -0800	[thread overview]
Message-ID: <Z5wgZHnvu9EeE4xq@ghost> (raw)
In-Reply-To: <20250131-unknotted-yoga-bccacad0c6d3@spud>

On Fri, Jan 31, 2025 at 12:43:12AM +0000, Conor Dooley wrote:
> On Thu, Jan 30, 2025 at 02:58:49PM -0800, Charlie Jenkins wrote:
> > On Wed, Jan 29, 2025 at 04:19:58PM +0000, Conor Dooley wrote:
> > > On Wed, Jan 29, 2025 at 02:17:03PM +0100, Aleksandar Rikalo wrote:
> > > > From: Djordje Todorovic <djordje.todorovic@htecgroup.com>
> > > > 
> > > > The riscv MIPS P8700 uses a different opcode for PAUSE.
> > > > It is a ‘hint’ encoding of the SLLI instruction, with rd=0, rs1=0 and
> > > > imm=5. It will behave as a NOP instruction if no additional behavior
> > > > beyond that of SLLI is implemented.
> > > 
> > > You say p8700, but the erratum will be applied on all systems that are
> > > identified as using a mips cpu. Why's that?
> > > 
> > > > +void mips_errata_patch_func(struct alt_entry *begin,
> > > > +					     struct alt_entry *end,
> > > > +					     unsigned long archid,
> > > > +					     unsigned long impid,
> > > > +					     unsigned int stage)
> > > > +{
> > > > +	struct alt_entry *alt;
> > > > +
> > > > +	BUILD_BUG_ON(ERRATA_MIPS_NUMBER >= RISCV_VENDOR_EXT_ALTERNATIVES_BASE);
> > > > +
> > > > +	if (stage == RISCV_ALTERNATIVES_EARLY_BOOT)
> > > > +		return;
> > > > +
> > > > +	for (alt = begin; alt < end; alt++) {
> > > > +		if (alt->vendor_id != MIPS_VENDOR_ID)
> > > > +			continue;
> > > > +
> > > > +		if (alt->patch_id >= ERRATA_MIPS_NUMBER) {
> > > > +			WARN(1, "MIPS errata id:%d not in kernel errata list\n",
> > > > +			     alt->patch_id);
> > > > +			continue;
> > > > +		}
> > > > +
> > > > +		mutex_lock(&text_mutex);
> > > > +		patch_text_nosync(ALT_OLD_PTR(alt), ALT_ALT_PTR(alt), alt->alt_len);
> > > > +		mutex_unlock(&text_mutex);
> > > > +	}
> > > > +}
> > > 
> > > > diff --git a/tools/arch/riscv/include/asm/vdso/processor.h b/tools/arch/riscv/include/asm/vdso/processor.h
> > > > index 662aca039848..880f26a24f69 100644
> > > > --- a/tools/arch/riscv/include/asm/vdso/processor.h
> > > > +++ b/tools/arch/riscv/include/asm/vdso/processor.h
> > > > @@ -14,7 +14,10 @@ static inline void cpu_relax(void)
> > > >  	__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
> > > >  #endif
> > > >  
> > > > -#ifdef CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
> > > > +#ifdef CONFIG_ERRATA_MIPS_P8700_PAUSE_OPCODE
> > > > +    /* MIPS P8700 pause opcode */
> > > > +    __asm__ __volatile__ (".4byte 0x00501013");
> > > > +#elif CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE
> > > >  	/*
> > > >  	 * Reduce instruction retirement.
> > > >  	 * This assumes the PC changes.
> > > 
> > > What about when the erratum is enabled and the toolchain supports
> > > Zihintpause?
> > 
> > So the other way to do this is having an hwprobe call to check if the
> > currently running processor is effected by this. However I was concerned
> > about the performance penalty of calling hwprobe here in the previous
> > version so I had suggested to use a flag instead so there is not the
> > penalty on other architectures. This does make it invalid to enable
> > this errata in the defconfig. This is a precedent for how we want to
> > handle errata in tools.
> 
> Gonna have to be marked non-portable then, if enabling it results in
> tools that might malfunction on other platforms.
> 
> > > Why don't you use the same implementation as the !tools
> > > copy of the header? (I'm not sure why they're different in the first
> > > place).
> > 
> > It is different because the headers in tools are userspace so it doesn't
> > make sense to have alternatives.
> 
> I assume that's an answer to the first part, and not the bit in
> brackets since the "first place" difference is about using the .4byte
> versus having an ifdef/else and you're talking about alternatives.
> That looks to have been some sort of sync issue or oversight in
> 6da111574baff, no?

Yeah it was a response to the first part.

As for the second part, yes it look it was a syncing issue.

- Charlie


  reply	other threads:[~2025-01-31  0:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-29 13:17 [PATCH v3] riscv: Fix the PAUSE Opcode for MIPS P8700 Aleksandar Rikalo
2025-01-29 13:17 ` Aleksandar Rikalo
2025-01-29 16:19 ` Conor Dooley
2025-01-29 16:19   ` Conor Dooley
2025-01-30 22:58   ` Charlie Jenkins
2025-01-30 22:58     ` Charlie Jenkins
2025-01-31  0:43     ` Conor Dooley
2025-01-31  0:43       ` Conor Dooley
2025-01-31  0:59       ` Charlie Jenkins [this message]
2025-01-31  0:59         ` Charlie Jenkins
2025-01-31  7:20         ` Andrew Jones
2025-01-31  7:20           ` Andrew Jones
2025-01-30 23:00 ` Charlie Jenkins
2025-01-30 23:00   ` Charlie Jenkins
2025-02-05 15:44 ` Palmer Dabbelt
2025-02-05 15:44   ` Palmer Dabbelt
2025-03-19 12:26   ` Djordje Todorovic
2025-03-19 12:26     ` Djordje Todorovic
2025-03-25  9:12     ` Alexandre Ghiti
2025-03-25  9:12       ` Alexandre Ghiti

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=Z5wgZHnvu9EeE4xq@ghost \
    --to=charlie@rivosinc.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arikalo@gmail.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=conor@kernel.org \
    --cc=djordje.todorovic@htecgroup.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.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.