From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by mail.toke.dk (Postfix) with ESMTPS id 5D6DC9B34F2 for ; Sat, 5 Nov 2022 01:40:12 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=arIslphX Received: by mail-pl1-x62d.google.com with SMTP id b21so6326331plc.9 for ; Fri, 04 Nov 2022 17:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5UShT6hdueBiRdAV7jVMEI7CsgXCqm/S1eXi9m2GGnc=; b=arIslphXQrB8c9btvdBdRAdFgXMzjaIkBLhhffsOcH9DrsQ4T5Jot68rWWlzKH9W6o qYc9xywf11IJu04wjguIKyE7/YtsGTig9BNr/yax5WkTzDrX1Vwc1C1beIqizT8ejkj6 /CNx/wF7WW0E4VOeCW11rFQjZy44sr1Z26cTFQ0Rx/gaIa4ePKtQoHfPPMkiSu1fnNHD xvVK+2WWrSd5Qp4vXKz/Ho84htLyPCcoJHUgRqjQr8MAt/X6aWn5yUb41KIa7GotKz+9 YZawMsOEfM0YIppEIZW5dQoJYvEWaxRzJbYcundDC7iKNmy7CACzlVxfZgn7atNUWuMr 7z7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5UShT6hdueBiRdAV7jVMEI7CsgXCqm/S1eXi9m2GGnc=; b=Onh4RcjqjKsT8N5am1X+8bVH/rpMBdLMi1lbvlURWrv8iCh0ybnuC4SElpDWyx8/HG +oraj95gCGNPQzCzRzFl7OV85A+7SoPhom8NQIbr03FACIPwlQibyILiajemlRH/7hUO M80UOqX+BxOcbFWVGZKlsU2dZMA3HNf8Vh0FYBBzz3pvw4GBvFLAdWMNfFkv7MBzIhpw Roa65UByhacr/U3H4YxLX7sRQyIG4JC3ejaa5bDLTla1CF2uS7QzAcTmfzYR6+p02/iM duE0Mq3OHXtxu5RlwMc/HrxTJ95uI+YQc0icIqmXywWtLH0U1o9Ub6z2CL04uCQE+F/P q1bQ== X-Gm-Message-State: ACrzQf0+vzfmUJWiBUU+MIYKsF5YXSZiI14UwefNNtUv0zmTbHRc1RfU wy+3Vqjkb04JC9ErkKpaAZg= X-Google-Smtp-Source: AMsMyM4Ca7HMgqKRlFHz9Gpflsx7i84XS07B6VYQhdOaRMU1IpPU6nqmpSrcf1JzMsBqQzDeQXKNZw== X-Received: by 2002:a17:902:ab8f:b0:185:46d3:8c96 with SMTP id f15-20020a170902ab8f00b0018546d38c96mr39531149plr.136.1667608810381; Fri, 04 Nov 2022 17:40:10 -0700 (PDT) Received: from macbook-pro-5.dhcp.thefacebook.com ([2620:10d:c090:400::5:49d4]) by smtp.gmail.com with ESMTPSA id x29-20020aa7941d000000b0056bf4f8d542sm203168pfo.74.2022.11.04.17.40.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 17:40:09 -0700 (PDT) Date: Fri, 4 Nov 2022 17:40:05 -0700 From: Alexei Starovoitov To: Stanislav Fomichev Message-ID: <20221105004005.pfdsaitg6phb6vxm@macbook-pro-5.dhcp.thefacebook.com> References: <20221104032532.1615099-1-sdf@google.com> <20221104032532.1615099-9-sdf@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221104032532.1615099-9-sdf@google.com> Message-ID-Hash: QKQDYQAPNFC7TC2UPIEMDOUNGRK3OPOV X-Message-ID-Hash: QKQDYQAPNFC7TC2UPIEMDOUNGRK3OPOV X-MailFrom: alexei.starovoitov@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v2 08/14] bpf: Helper to simplify calling kernel routines from unrolled kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Nov 03, 2022 at 08:25:26PM -0700, Stanislav Fomichev wrote: > When we need to call the kernel function from the unrolled > kfunc, we have to take extra care: r6-r9 belong to the callee, > not us, so we can't use these registers to stash our r1. > > We use the same trick we use elsewhere: ask the user > to provide extra on-stack storage. > > Also, note, the program being called has to receive and > return the context. > > Cc: John Fastabend > Cc: David Ahern > Cc: Martin KaFai Lau > Cc: Jakub Kicinski > Cc: Willem de Bruijn > Cc: Jesper Dangaard Brouer > Cc: Anatoly Burakov > Cc: Alexander Lobakin > Cc: Magnus Karlsson > Cc: Maryam Tahhan > Cc: xdp-hints@xdp-project.net > Cc: netdev@vger.kernel.org > Signed-off-by: Stanislav Fomichev > --- > include/net/xdp.h | 4 ++++ > net/core/xdp.c | 24 +++++++++++++++++++++++- > 2 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/include/net/xdp.h b/include/net/xdp.h > index 8c97c6996172..09c05d1da69c 100644 > --- a/include/net/xdp.h > +++ b/include/net/xdp.h > @@ -440,10 +440,14 @@ static inline u32 xdp_metadata_kfunc_id(int id) > return xdp_metadata_kfunc_ids.pairs[id].id; > } > void xdp_metadata_export_to_skb(const struct bpf_prog *prog, struct bpf_patch *patch); > +void xdp_kfunc_call_preserving_r1(struct bpf_patch *patch, size_t r0_offset, > + void *kfunc); > #else > #define xdp_metadata_magic 0 > static inline u32 xdp_metadata_kfunc_id(int id) { return 0; } > static void xdp_metadata_export_to_skb(const struct bpf_prog *prog, struct bpf_patch *patch) { return 0; } > +static void xdp_kfunc_call_preserving_r1(struct bpf_patch *patch, size_t r0_offset, > + void *kfunc) {} > #endif > > #endif /* __LINUX_NET_XDP_H__ */ > diff --git a/net/core/xdp.c b/net/core/xdp.c > index 8204fa05c5e9..16dd7850b9b0 100644 > --- a/net/core/xdp.c > +++ b/net/core/xdp.c > @@ -737,6 +737,7 @@ BTF_SET8_START_GLOBAL(xdp_metadata_kfunc_ids) > XDP_METADATA_KFUNC_xxx > #undef XDP_METADATA_KFUNC > BTF_SET8_END(xdp_metadata_kfunc_ids) > +EXPORT_SYMBOL(xdp_metadata_kfunc_ids); > > /* Make sure userspace doesn't depend on our layout by using > * different pseudo-generated magic value. > @@ -756,7 +757,8 @@ static const struct btf_kfunc_id_set xdp_metadata_kfunc_set = { > * > * The above also means we _cannot_ easily call any other helper/kfunc > * because there is no place for us to preserve our R1 argument; > - * existing R6-R9 belong to the callee. > + * existing R6-R9 belong to the callee. For the cases where calling into > + * the kernel is the only option, see xdp_kfunc_call_preserving_r1. > */ > void xdp_metadata_export_to_skb(const struct bpf_prog *prog, struct bpf_patch *patch) > { > @@ -832,6 +834,26 @@ void xdp_metadata_export_to_skb(const struct bpf_prog *prog, struct bpf_patch *p > > bpf_patch_resolve_jmp(patch); > } > +EXPORT_SYMBOL(xdp_metadata_export_to_skb); > + > +/* Helper to generate the bytecode that calls the supplied kfunc. > + * The kfunc has to accept a pointer to the context and return the > + * same pointer back. The user also has to supply an offset within > + * the context to store r0. > + */ > +void xdp_kfunc_call_preserving_r1(struct bpf_patch *patch, size_t r0_offset, > + void *kfunc) > +{ > + bpf_patch_append(patch, > + /* r0 = kfunc(r1); */ > + BPF_EMIT_CALL(kfunc), > + /* r1 = r0; */ > + BPF_MOV64_REG(BPF_REG_1, BPF_REG_0), > + /* r0 = *(r1 + r0_offset); */ > + BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, r0_offset), > + ); > +} > +EXPORT_SYMBOL(xdp_kfunc_call_preserving_r1); That's one twisted logic :) I guess it works for preserving r1, but r2-r5 are gone and r6-r9 cannot be touched. So it works for the most basic case of returning single value from that additional kfunc while preserving single r1. I'm afraid that will be very limiting moving forward. imo we need push/pop insns. It shouldn't difficult to add to the interpreter and JITs. Since this patching is done after verificaiton they will be kernel internal insns. Like we have BPF_REG_AX internal reg.