Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2828540ybd; Mon, 24 Jun 2019 13:29:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyXnIUW4RFz2FofMkSeJibdzamgZPkbshsNtweiLFELDC+UX0C9Qcq/vKk+LY9YFMHchYdG X-Received: by 2002:a65:418d:: with SMTP id a13mr35253265pgq.332.1561408187078; Mon, 24 Jun 2019 13:29:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561408187; cv=none; d=google.com; s=arc-20160816; b=VHU2H3GESSnA7f+Ll3ka4EUSOkrW8WEjkF9Ef8WSK2GisuB4O4PsHJfxBXBSfudgTY Fa9F68JzG4pAAXfaMU+w6NjdxArNIFNOWom/BTykaACsPnjw9dpjItKXVyywqI8HF+xV P+XGW1cu/SRQ1y1zD3pbNwVljSguaSapZ1vhyFz5dcwO3FeDU6xfa/sj+SH4tD3V0Qrc rIf7ZWlqJ+KUFhZzZcQbVWAIShQLvSFe9oMgFEmDRFX1DVVMXmk8o6A5U5NOjevXKeC/ 9WgxvZlRaVIP29bJfx1B+1b65ZIGd6L4Kl2CNBIRFCgKJq/0miDXEsbYdZEWJRCOB+xK /3Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:date:in-reply-to:message-id :subject:cc:to:from:user-agent:references:dkim-signature; bh=DzGlPYsIYshbD5peGKifO8l46y0lKsTTIsT4YjNzT5E=; b=jL/FwMR1i2TXvYkj0b9l4VwDx2xlULo40F6rU6cty5lKdFHg4Yyg+pnN+kejWlWrfb V8hpJW0ulsmGmIaB6C+Y/koK+A5Ov94tg6d0VNKcXqHWTwodXRhlWPU5osnvexc17LEz rGDKwJ0LZY4vDgecoSToAscs7atCTskRi6gywFAu30n5iQN0c+y2s9SYz2TrRLhEMkAp R107PF2xPgCzq7vUJZ2WBI6hPpKo/xbALBrUE8aU8X1vrnn+h2wqV06t+oYyUpFuVcV+ qhoif2WIExMUwbEyGBW2jQHrk5vDDXtbvTKh1iVsDSG80GRu5tTKrkyf6LxmuBb5ixSj SGZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@netronome-com.20150623.gappssmtp.com header.s=20150623 header.b=d6bKmA1q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c142si11451554pfc.194.2019.06.24.13.29.30; Mon, 24 Jun 2019 13:29:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@netronome-com.20150623.gappssmtp.com header.s=20150623 header.b=d6bKmA1q; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732176AbfFXQpt (ORCPT + 99 others); Mon, 24 Jun 2019 12:45:49 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:40463 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727847AbfFXQpt (ORCPT ); Mon, 24 Jun 2019 12:45:49 -0400 Received: by mail-wm1-f66.google.com with SMTP id v19so31001wmj.5 for ; Mon, 24 Jun 2019 09:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:message-id:in-reply-to :date:mime-version; bh=DzGlPYsIYshbD5peGKifO8l46y0lKsTTIsT4YjNzT5E=; b=d6bKmA1qg0uC0Ie/B+rKeOICs7HZyVW8m4zo5CufVyG8tVEYsVvxLbE/SN124rH9p3 06yUcEvuoj+0PcroXaMiWv8HRvVCQeLqaMGAjw8YiGZA+5OdDouYUSYBBjcOtnTezmpB mSev/yoU1rb28ZElCOVgrod/eoj6MrAaSrfoqh6HliP3cARmrjnP7lmUG96MesS3+Ku0 J5V5MSG5H8SsQIMgau0YDGSiMF5J1gZFIuklMrMYbGDIDGDq/l78UhoMTq3J/cwJ4v7X mPdQecNR4EHgr/JIOVaSbkfVdT2FxX1qxupmrqOEyO1iKOT+/uX5o+xyqn6TbPQHpqBd X2TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :message-id:in-reply-to:date:mime-version; bh=DzGlPYsIYshbD5peGKifO8l46y0lKsTTIsT4YjNzT5E=; b=T8ad89Az7rFl6jbjddVrHPOurC5N2dbSQGC2IyJqcTld01eQqvMgM+yZ5znTjCbCph 8eC1WjyjvLstBm10+TuGZ7wDIduSS+XkYZiL0bin32m4C6OlJDHgGeucTniW1vvLJtgl 5tanbb6UIZ8NpH9spHtaizBDrNTXfvsroLSRURNPcrVP8GeWqunh2B2uR2guMX91petG LJuQixxV8gWMx10Ug2czlC22iongCyWWRYfL1fw0B1wJwYWZGpfBJGtcku3wH0D6kwrn v4gldbdzR0yIssNZTMufbZVPmd7RELaHq54VI8teIN5TDPr7P2NufaCHjN8DV7WTbNbi WIhg== X-Gm-Message-State: APjAAAVQOPsm/ecKxPxVsfUlWg8N0VpMHGMluuR9OFMWDrLBuQ6sYids Ulovt3bbXqst42S5f4t+oc2WsQ== X-Received: by 2002:a1c:4d6:: with SMTP id 205mr15402634wme.148.1561394746919; Mon, 24 Jun 2019 09:45:46 -0700 (PDT) Received: from LAPTOP-V3S7NLPL ([217.38.71.146]) by smtp.gmail.com with ESMTPSA id 15sm21315wmk.34.2019.06.24.09.45.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 24 Jun 2019 09:45:46 -0700 (PDT) References: <20190621225938.27030-1-lukenels@cs.washington.edu> User-agent: mu4e 0.9.18; emacs 25.2.2 From: Jiong Wang To: Luke Nelson Cc: Luke Nelson , Xi Wang , Palmer Dabbelt , Albert Ou , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [RFC PATCH bpf-next] RV32G eBPF JIT Message-ID: <87h88f9bm3.fsf@netronome.com> In-reply-to: <20190621225938.27030-1-lukenels@cs.washington.edu> Date: Mon, 24 Jun 2019 17:45:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Luke Nelson writes: > From: Luke Nelson > > This is an eBPF JIT for RV32G, adapted from the JIT for RV64G. > Any feedback would be greatly appreciated. > > It passes 359 out of 378 tests in test_bpf.ko. The failing tests are > features that are not supported right now: > - ALU64 DIV/MOD: > These require loops to emulate on 32-bit hardware, > and are not supported on other 32-bit JITs like > ARM32. > - BPF_XADD | BPF_DW: > RV32G does not have atomic instructions for operating > on double words. This is similar to ARM32. > - Tail calls: > I'm working on adding support for these now, but couldn't > find any test cases that use them. What's the best way > of testing tail call code? > - Far branches > These are not supported in RV64G either. > > There are two main changes required for this to work compared to the > RV64 JIT. > > First, eBPF registers are 64-bit, while RV32G registers are 32-bit. > I take an approach similar to ARM32: most BPF registers map directly to > 2 RISC-V registers, while some reside in stack scratch space and must > be saved / restored when used. > > Second, many 64-bit ALU operations do not trivially map to 32-bit > operations. Operations that move bits between high and low words, such > as ADD, LSH, MUL, and others must emulate the 64-bit behavior in terms > of 32-bit instructions. > > Signed-off-by: Luke Nelson > Cc: Xi Wang > --- > arch/riscv/Kconfig | 2 +- > arch/riscv/net/Makefile | 7 +- > arch/riscv/net/bpf_jit_comp32.c | 1460 +++++++++++++++++++++++++++++++ > 3 files changed, 1467 insertions(+), 2 deletions(-) > create mode 100644 arch/riscv/net/bpf_jit_comp32.c > > +static void rv32_bpf_put_reg32(const s8 *reg, const s8 *src, > + struct rv_jit_context *ctx) > +{ > + if (is_stacked(reg[1])) { > + emit(rv_sw(RV_REG_FP, reg[1], src[1]), ctx); > + emit(rv_sw(RV_REG_FP, reg[0], RV_REG_ZERO), ctx); > + } else { > + emit(rv_addi(reg[0], RV_REG_ZERO, 0), ctx); > + } > +} > + Looks to me 32-bit optimization is not enabled. If you define bpf_jit_needs_zext to return true bool bpf_jit_needs_zext(void) { return true; } Then you don't need to zero high 32-bit when writing 32-bit sub-register and you just need to implement the explicit zero extension insn which is a special variant of BPF_MOV. This can save quite a few instructions. RV64 and arches like arm has implemented this, please search "aux->verifier_zext". And there is a doc for this optimization: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_design_QA.rst#n168 Regards, Jiong