From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FE30C004C9 for ; Fri, 3 May 2019 10:43:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40F002087F for ; Fri, 3 May 2019 10:43:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="v4ZxxQ1K" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727484AbfECKnv (ORCPT ); Fri, 3 May 2019 06:43:51 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:33053 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727276AbfECKnt (ORCPT ); Fri, 3 May 2019 06:43:49 -0400 Received: by mail-wr1-f65.google.com with SMTP id e28so7299284wra.0 for ; Fri, 03 May 2019 03:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=K4gLqJ4SgDOsgXMmICWdVA0zCxYikPtUo1d3XLqhgFA=; b=v4ZxxQ1KTyQ5O3GeNw5PvYYAdDrhFj+uHrpzgQVuLgBCOWg8q4gl1TQAPHFVHG8G0M TEKqIFHWoSQPaRAhxznmu7UERdvAqkSOVIpwS83PoA2vHPp3SsDFBgZJRCYdwHSUbpS0 c2FaEXJdqSMJxJk55GacCwDsKNicaaN9KTs/SktNyMOP4s7IPRBoOdEKCJfTbbiX7c3P bAVEWJU7Ozt2t+tRSpLU0LjDSWyr5GTGu5HJPn2zPb/ac21AR5SJpAZktY659TS8Fl3q snq8Dh7vRZbcw8VWDRNvClUyOG67nOXuUTAt8W8j57fXrW7nzfz1+r3TQQySTwFpri5z 5hyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=K4gLqJ4SgDOsgXMmICWdVA0zCxYikPtUo1d3XLqhgFA=; b=g6C8eeCXXUYmmZn44mqqm+IEvcDT2CKSDxczAU+E9I8DUtjuYHj2mr/rUaSL1kjn2r GOs+pMssHijq6Oi1qUbqyuNt45dDiXfHUe7IrunK4EBd6kXs9oFHXBiencnldwzUV9PI LWbW2SdhSmAqMnQ679Gp3ZkMbLEzjrgCVSjBbf7cWJcVaKUN3UBbcC/6YZXRJ2YaNU0r RxopmlrqeGJ4x07obnKBR3bbMp3zi75RhroaszBregrAnQG9WRhQfJl2dF8wJvAPHeuZ rNysuL/1GDXPMSJ88w9b7fuD0uruc4i0fGklcgGmVgKhXt3fPhcue2SRYvmiUD9hMsiK gILg== X-Gm-Message-State: APjAAAVvNuRcle3DAk+THxWgQvUeVnOBM3ltf9+EhOtk1grfs8kwItqy /ukp7nu5EgRU8XuyXwgNUlRClw== X-Google-Smtp-Source: APXvYqxmES30jzauIQvZznWOLf6CJ5RhObBl0zMx451X3bpaaoUw5IVsoYJ1tggNqzvt+fwqfUwyeQ== X-Received: by 2002:a5d:4942:: with SMTP id r2mr6157661wrs.159.1556880227408; Fri, 03 May 2019 03:43:47 -0700 (PDT) Received: from cbtest28.netronome.com ([217.38.71.146]) by smtp.gmail.com with ESMTPSA id r29sm1716999wra.56.2019.05.03.03.43.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 May 2019 03:43:46 -0700 (PDT) From: Jiong Wang To: alexei.starovoitov@gmail.com, daniel@iogearbox.net Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, oss-drivers@netronome.com, Jiong Wang Subject: [PATCH v6 bpf-next 04/17] bpf: introduce new alu insn BPF_ZEXT for explicit zero extension Date: Fri, 3 May 2019 11:42:31 +0100 Message-Id: <1556880164-10689-5-git-send-email-jiong.wang@netronome.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1556880164-10689-1-git-send-email-jiong.wang@netronome.com> References: <1556880164-10689-1-git-send-email-jiong.wang@netronome.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This patch introduce new alu32 insn BPF_ZEXT, and allocate the unused opcode 0xe0 to it. Compared with the other alu32 insns, zero extension on low 32-bit is the only semantics for this instruction. It also allows various JIT back-ends to do optimal zero extension code-gen. BPF_ZEXT is supposed to be encoded with BPF_ALU only, and is supposed to be generated by the latter 32-bit optimization code inside verifier for those arches that do not support hardware implicit zero extension only. It is not supposed to be used in user's program directly at the moment. Therefore, no need to recognize it inside generic verification code. It just need to be supported for execution on interpreter or related JIT back-ends. Signed-off-by: Jiong Wang --- Documentation/networking/filter.txt | 10 ++++++++++ include/uapi/linux/bpf.h | 3 +++ kernel/bpf/core.c | 4 ++++ tools/include/uapi/linux/bpf.h | 3 +++ 4 files changed, 20 insertions(+) diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 319e5e0..1cb3e42 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -903,6 +903,16 @@ If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of: BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ BPF_END 0xd0 /* eBPF only: endianness conversion */ + BPF_ZEXT 0xe0 /* eBPF BPF_ALU only: zero-extends low 32-bit */ + +Compared with BPF_ALU | BPF_MOV which zero-extends low 32-bit implicitly, +BPF_ALU | BPF_ZEXT zero-extends low 32-bit explicitly. Such zero extension is +not the main semantics for the prior, but is for the latter. Therefore, JIT +optimizer could optimize out the zero extension for the prior when it is +concluded safe to do so, but should never do such optimization for the latter. +LLVM compiler won't generate BPF_ZEXT, and hand written assembly is not supposed +to use it. Verifier 32-bit optimization pass, which removes zero extension +semantics from the other BPF_ALU instructions, is the only place generates it. If BPF_CLASS(code) == BPF_JMP or BPF_JMP32 [ in eBPF ], BPF_OP(code) is one of: diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 72336ba..22ccdf4 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -32,6 +32,9 @@ #define BPF_FROM_LE BPF_TO_LE #define BPF_FROM_BE BPF_TO_BE +/* zero extend low 32-bit */ +#define BPF_ZEXT 0xe0 + /* jmp encodings */ #define BPF_JNE 0x50 /* jump != */ #define BPF_JLT 0xa0 /* LT is unsigned, '<' */ diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index 2792eda..ee8703d 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -1152,6 +1152,7 @@ EXPORT_SYMBOL_GPL(__bpf_call_base); INSN_2(ALU, NEG), \ INSN_3(ALU, END, TO_BE), \ INSN_3(ALU, END, TO_LE), \ + INSN_2(ALU, ZEXT), \ /* Immediate based. */ \ INSN_3(ALU, ADD, K), \ INSN_3(ALU, SUB, K), \ @@ -1352,6 +1353,9 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) ALU64_NEG: DST = -DST; CONT; + ALU_ZEXT: + DST = (u32) DST; + CONT; ALU_MOV_X: DST = (u32) SRC; CONT; diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index 72336ba..22ccdf4 100644 --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -32,6 +32,9 @@ #define BPF_FROM_LE BPF_TO_LE #define BPF_FROM_BE BPF_TO_BE +/* zero extend low 32-bit */ +#define BPF_ZEXT 0xe0 + /* jmp encodings */ #define BPF_JNE 0x50 /* jump != */ #define BPF_JLT 0xa0 /* LT is unsigned, '<' */ -- 2.7.4