All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: kernel test robot <lkp@intel.com>,
	oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Sohil Mehta <sohil.mehta@intel.com>,
	linux-crypto@vger.kernel.org, linux-mips@vger.kernel.org,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: lib/crypto/mips/poly1305-core.S:95: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $8,0+3($5)'
Date: Mon, 30 Mar 2026 18:48:37 -0700	[thread overview]
Message-ID: <20260331014837.GC5190@sol> (raw)
In-Reply-To: <alpine.DEB.2.21.2603310147220.60268@angie.orcam.me.uk>

On Tue, Mar 31, 2026 at 02:01:44AM +0100, Maciej W. Rozycki wrote:
> On Mon, 30 Mar 2026, Eric Biggers wrote:
> 
> > > All errors (new ones prefixed by >>):
> > > 
> > >    lib/crypto/mips/poly1305-core.S: Assembler messages:
> > > >> lib/crypto/mips/poly1305-core.S:95: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $8,0+3($5)'
> > >    lib/crypto/mips/poly1305-core.S:96: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $9,4+3($5)'
> > >    lib/crypto/mips/poly1305-core.S:97: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $10,8+3($5)'
> > >    lib/crypto/mips/poly1305-core.S:98: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $11,12+3($5)'
> > 
> > This isn't new.  It was first reported in 2021:
> > https://lore.kernel.org/all/202108040636.P6t1LvPP-lkp@intel.com/
> > 
> > It's caused by:
> > 
> > CONFIG_64BIT=n causes the 32-bit Poly1305 assembly code to be generated.
> > That code checks the _MIPS_ARCH_MIPS32R6 macro.  But, the code is
> > actually built with -march=mips64r6, due to CONFIG_CPU_MIPS64_R6=y.
> > Thus _MIPS_ARCH_MIPS32R6 is not defined; _MIPS_ARCH_MIPS64R6 is defined
> > instead.  So the wrong code gets built.
> > 
> > Maybe someone from linux-mips@vger.kernel.org can confirm whether
> > CONFIG_64BIT=n && CONFIG_CPU_MIPS64_R6=y actually makes sense?
> 
>  Absolutely, you can build a 32-bit kernel for and run on 64-bit hardware 
> and we have supported it since forever across all the MIPS architecture 
> revisions.
> 
>  You probably want to check for CONFIG_CPU_MIPSR6 instead (and similarly 
> for CONFIG_CPU_MIPSR2, etc.).

Okay, but does it make sense to use -march=mips64r6 in that case,
instead of -march=mips32r6?  I guess you get something that uses the
32-bit ABI but is free to use 64-bit instructions?  It looks like
poly1305-mips.pl doesn't really support that combination: it just has
32-bit ABI + 32-bit instructions, and 64-bit ABI + 64-bit instructions.

Maybe it would be easiest to always compile poly1305-mips.pl with the
corresponding mips32 flag when CONFIG_64BIT is unset?  Note: since
poly1305-mips.pl was taken from an external source
(https://github.com/dot-asm/cryptogams/blob/master/mips/poly1305-mips.pl),
modifying the build system to pass the appropriate flag might be
preferable to extensive local patching of that file.

- Eric

  reply	other threads:[~2026-03-31  1:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20 17:47 lib/crypto/mips/poly1305-core.S:95: Error: opcode not supported on this processor: mips64r6 (mips64r6) `lwl $8,0+3($5)' kernel test robot
2026-03-30 20:37 ` Eric Biggers
2026-03-31  1:01   ` Maciej W. Rozycki
2026-03-31  1:48     ` Eric Biggers [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-05-21 20:01 kernel test robot

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=20260331014837.GC5190@sol \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=macro@orcam.me.uk \
    --cc=martin.petersen@oracle.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=sohil.mehta@intel.com \
    --cc=tsbogend@alpha.franken.de \
    /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.