The MIPS JITs select division and modulo implementations from the BPF
class and opcode, but did not interpret the opcode-specific insn->off
value that selects signed DIV/MOD semantics. Negative operands therefore
produced unsigned results.

Factor div/mod emission into helpers, add the missing signed uasm
operations, and interpret the raw offset only in div/mod-specific paths.
On 32-bit MIPS, use signed 64-bit helpers for ALU64 operations.

The base, each intermediate patch boundary, and the full series were built
and run under QEMU with CONFIG_BPF_JIT_ALWAYS_ON=y on MIPS32r2, MIPS32r6,
MIPS64r2, and MIPS64r6. Fourteen of sixteen signed DIV/MOD cases failed on
the base and after the two preparatory patches; all sixteen passed and
remained JITed with the full series. A big-endian MIPS32 base/full
comparison produced the same result. Because patch 2 extends the shared
uasm interface, that intermediate revision was also built with a microMIPS
configuration.

v3:
- split the generic uasm additions into a separate provider patch
- propagate raw insn->off and decode it only in div/mod-specific paths
- keep the signed remainder quotient in s64
- add the requested short comments to the div/mod emitters
- refresh onto bpf-next at d114bb989367
- add intermediate-boundary, big-endian, and microMIPS validation

v2: https://lore.kernel.org/bpf/20260729162931.2369353-1-main.kalliope@gmail.com/
v1: https://lore.kernel.org/bpf/20260716211055.2569433-1-main.kalliope@gmail.com/

Nicholas Dudar (3):
  bpf, mips: Factor out div/mod emission helpers
  MIPS: uasm: Add signed div/mod emitters
  bpf, mips: Add support for BPF_SDIV and BPF_SMOD

 arch/mips/include/asm/uasm.h   |  6 +++
 arch/mips/mm/uasm-mips.c       | 10 +++++
 arch/mips/mm/uasm.c            | 20 +++++++---
 arch/mips/net/bpf_jit_comp.c   | 55 +++++++++++++++++++-------
 arch/mips/net/bpf_jit_comp.h   |  4 +-
 arch/mips/net/bpf_jit_comp32.c | 29 +++++++++-----
 arch/mips/net/bpf_jit_comp64.c | 71 +++++++++++++++++++++++-----------
 7 files changed, 140 insertions(+), 55 deletions(-)


base-commit: d114bb98936770c501c958bf2bc5fb6b7c0bad7b

Hi Nicholas,

Thanks for the v3 series. It looks good.

However, i am currently on holiday and do not have access to my full
QEMU test rig right now. I have verified your changes with the
test_bpf selftests on mips32 with QEMU on my laptop, but the remaining
arch variants will have to wait until I am back in about 12 days. I
would like to do that before giving my final approval.

Please proceed with the remaining opcodes in the meantime. I will do
the same on my part as we discussed, and then we can wrap up this
whole v4 compliance work when I am back.

Thanks,
Johan

> Please proceed with the remaining opcodes in the meantime. I will do
> the same on my part as we discussed, and then we can wrap up this
> whole v4 compliance work when I am back.

Sorry to bother you while you're away, I hope the holiday is going well.
No rush on this, but one ordering dependency fell out of my testing.
MOVSX and SDIV/SMOD need to land before MEMSX, BSWAP, or JMP32_JA.

MEMSX, BSWAP, and JMP32_JA are currently unhandled, so any program
containing one causes the MIPS JIT to abandon compilation. Adding support
for one removes the fallback, so a mixed program can reach the existing
MOV or DIV/MOD paths before their off encodings are supported and be
miscompiled.

I plan to post MOVSX today. For MEMSX, I will base it after MOVSX and
SDIV/SMOD and call out the dependency in the commit message. This avoids
carrying a temporary fail-closed check. Does that ordering work for BSWAP
and JMP32_JA?

Thanks,
Nick

On Tue, Aug 18, 2026 at 3:11 PM Nicholas Dudar <main.kalliope@gmail.com> wrote:
> I plan to post MOVSX today. For MEMSX, I will base it after MOVSX and
> SDIV/SMOD and call out the dependency in the commit message. This avoids
> carrying a temporary fail-closed check. Does that ordering work for BSWAP
> and JMP32_JA?

Yes, I think that should work fine. If I understand it correctly, I
would then add BSWAP and JMP32_JA on top of your patches? I plan to
take a look at this when I am back next week.

Thanks,
Johan

> If I understand it correctly, I would then add BSWAP and JMP32_JA on
> top of your patches?

Yes, please. The strict requirements are that SDIV/SMOD and MOVSX come
first. MEMSX, BSWAP, and JMP32_JA can then follow in any order, but
stacking BSWAP and JMP32_JA after all three series gives us a simple
shared base.

The MOVSX and MEMSX RFCs are here:

https://lore.kernel.org/bpf/20260819010523.1057789-1-main.kalliope@gmail.com/
https://lore.kernel.org/bpf/20260821024640.1601299-1-main.kalliope@gmail.com/

I plan to post the non-RFC versions after bpf-next reopens, preserving
that ordering.

Thanks,
Nick