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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 393A3C433E0 for ; Thu, 21 May 2020 18:59:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0CB2C20759 for ; Thu, 21 May 2020 18:59:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NLBndha6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729611AbgEUS67 (ORCPT ); Thu, 21 May 2020 14:58:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729603AbgEUS67 (ORCPT ); Thu, 21 May 2020 14:58:59 -0400 Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4ECEDC061A0E for ; Thu, 21 May 2020 11:58:59 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id a23so6401510qto.1 for ; Thu, 21 May 2020 11:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SkT32RVtASIP8CGRtZRQGHPZetvexkw0Tk4FcVWqhjg=; b=NLBndha66Sy1yrsslaj01OFsquN9NR9Sev1Ta0Rk/Hid8wn2NLGK11mLkL6bsP6ZqY zsrIgnAwcrCplfX1hLlydMpnDojF026r6/At060fM7HrWFKKQAkXXKJlI2waf9Cp/M8G PyZLilF3jsSjqFfOQ7rxsCCBemxXC8PQ1TyRxgnsEnWr1kBaEgoVrgFdq15zYDszxIXb JAve4oGyrD7BI6E2I0bYKl8qSkdtx7Qi58Hs5WBfTnOxRl94WchUFNZ37gVKkhvdOqPG FRczQXsXkXk0T3N3WMJfEQBjoYQpvWH0ziuCB92aeGLCFly2CnVM2TG4JksD6QgGRYqi kMSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SkT32RVtASIP8CGRtZRQGHPZetvexkw0Tk4FcVWqhjg=; b=uPHyDhM0V/OOD8CYOOH3DcMlHtrgkjb1ipQb6PkzpKTU5BeCJevU9Oe+tQtpgE50nb UnmqSD5ObMuLUJKqXNbL7SzsZhPPZIGfZo79DerbYvOQlP4PyLGW4zpTHMVjsKPjBQsu hyerKJ7syYsjKaZw/pnKmlsAdAMi0p2GGdRqaHuzzALWQ3iBKE9eQGeXqKDPGaR7iivq xvJayOq5HOdnZhVPvUDrnsE0DDiZO8Z/UhzqwQ44BT8/F+f57YqFRzDFurc/j5UnqHAM nF4TF1C52RwaaJwzBAVeVSGNE/xA+jxbv9+p92MwPbrWLoZErvhXybDo1AGOu4YMmuFE 0Jzg== X-Gm-Message-State: AOAM53089i1bIiBSqWXLbXA+NTtlWW4OiiyNRdUHDvhfMeaPraO1inyk MlQYicX0DZlJ5S0uKnUHdKL/kLBTRFdpRygerIvNFEPw X-Google-Smtp-Source: ABdhPJypriRPlj0CvQ6ikRZJeO6l4De45Vb/eg1K6EF8duX9O/XM5vOQ5sN4M0N5MKMyISo0vKdboclZMtDzmF8Fdkc= X-Received: by 2002:ac8:3a42:: with SMTP id w60mr2170488qte.141.1590087538460; Thu, 21 May 2020 11:58:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Nakryiko Date: Thu, 21 May 2020 11:58:47 -0700 Message-ID: Subject: Re: accessing global and per-cpu vars To: Alexei Starovoitov Cc: haoluo@google.com, Andrii Nakryiko , Arnaldo Carvalho de Melo , Daniel Borkmann , bpf , olegrom@google.com, Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, May 21, 2020 at 10:07 AM Alexei Starovoitov wrote: > > Hi, > > here are my notes from the bpf office hours today. > Does it sound as what we discussed? > > Steps to add incremental support to global vars: > 1. teach libbpf to replace "ld_imm64 rX, foo" with absolute address > of var "foo" by reading that value from kallsyms. > From the verifier point of view ld_imm64 instruction will look like it's > assigning large constant into a register. > The bpf prog would need to use bpf_probe_read_kernel() > to further access vars. yep > > 2. teach pahole to store ' A ' annotated kallsyms into vmlinux BTF as > BTF_KIND_VAR. > There are ~300 of them, so should be minimal increase in size. I thought we'd do that based on section name? Or we will actually teach pahole to extract kallsyms from vmlinux image? There was step 1.5 (or even 0.5) to see if it's feasible to add not just per-CPU variables as well. > > 3. teach libbpf to scan vmlinux BTF for vars and replace "ld_imm64 rX, foo" > with BPF_PSEUDO_BTF_ID. > From the verifier point of view 'ld_imm64 rX, 123 // pseudo_btf_id' > will be similar to ld_imm64 with pseudo_map_fd and pseudo_map_value. > The verifier will check btf_id and replace that with actual kernel address > at program load time. It will also know that exact type of 'rX' from there on. > That gives big performance win since bpf prog will be able to use > direct load instructions to access vars. yep > > 4. add bpf_per_cpu(var, cpu) helper. > It will accept 'var' in R1 and the verifier will enforce that R1 is > PTR_TO_BTF_ID type > and it's BTF_KIND_VAR and it's in per-cpu datasec. > The return value from that helper will be normal PTR_TO_BTF_ID, > so subsequent load instruction can use it directly. > Would be nice to have this helper without BTF requirement, > but I don't see how to make it safe without BTF at the moment. > Similarly bpf_this_cpu_ptr(var) helper could be necessary or > we may fold it into cpu == BPF_F_CURRENT_CPU as a single helper. separate helper sounds better to me, both from usability stand point, as well as not using extra register unnecessarily