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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 E1047C2B9F4 for ; Mon, 28 Jun 2021 11:19:29 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5F56661919 for ; Mon, 28 Jun 2021 11:19:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F56661919 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lxpIW-00011Z-Gx for qemu-devel@archiver.kernel.org; Mon, 28 Jun 2021 07:19:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lxpHj-0000KE-Et for qemu-devel@nongnu.org; Mon, 28 Jun 2021 07:18:39 -0400 Received: from mail-oi1-x22b.google.com ([2607:f8b0:4864:20::22b]:42974) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lxpHh-00035l-GX for qemu-devel@nongnu.org; Mon, 28 Jun 2021 07:18:39 -0400 Received: by mail-oi1-x22b.google.com with SMTP id o6so6988014oic.9 for ; Mon, 28 Jun 2021 04:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FQNDpSSlwwV4B/vu7797RqrPv/YAuT1bvP/u1aipXZ4=; b=bSIMbNI8LpXjvTUCyync1jaGUZARiYE2BVUKpja3HGfQowottkvnsCjMPdDzMeakgA uCyMbeGdc8nKF/vYfvKxGhUXqLpoCZQz/fVcRwwXIslt+ai1HixvCdCus/MXM7FGe2o/ j4gmRve49qrvGavWmAIZNCN2oTkASQvo4kANSIPhhNktIfh6k5+Qx/qm11CqctwYFMSG 2Jm4jm8wwxhHvOX2BJrfQ5QtwyeG0wN+aQ6odjUeJCQ1l2gyWROem7JAfIfcPwuoXQ+Z ZAnpGFUqWRXrXeh2yqi6SFaIKwwiEu9wsD9tEc2jPSsJiZ4PXKAIpsBc/svvhWI6jOnF Thiw== 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:content-transfer-encoding; bh=FQNDpSSlwwV4B/vu7797RqrPv/YAuT1bvP/u1aipXZ4=; b=QvZhZ1+PCjP0bvAeBsJEb6sx0cbeI16oChqcVQ0Nwg63AGtr3n79mAJ5EnwOThVy30 9Qxu/xwHzPnTIPgTet7a6cF27FSAZMX/0+ev1rU1owWPZDdDwQ5WVxhBzk2bLhUNXSKk VtPImM4kJAOlAeoVO/54FQt2HG4icj7zofQ8tX8EJTiZoXHP6KhpyOQKVw6wHQ4w1AJe FXeSwmHrQ3mkncLpPgf5DIr6PCPqX9udjQ7fAay6Fhl0wURJPH/pMOmrADP2MBLnKPvu Wx4C7DQK0B14RPqh0YeAW9Me2/iKUSrWa8WBCYlhEpH2WSiTmVgX2c/4HsbyLmgYkReS fe5A== X-Gm-Message-State: AOAM532aSrOMJUcs2U7MyqYXApkUm+cqtUuqUA3ercm+aQIh1vUq8YSe bYRNdKwCEyrUeFebl7fR2iTlEB42EaVjcp2GTE5QAg== X-Google-Smtp-Source: ABdhPJzHtwX7UzMEPgfAK0rJd18/9GE4uNWMNvMCEtinIzwp5vq/Wr57n/E7K9AqsuG5PUm4uZMg/eY4iB9C6jceQKQ= X-Received: by 2002:a54:4703:: with SMTP id k3mr15053935oik.91.1624879115408; Mon, 28 Jun 2021 04:18:35 -0700 (PDT) MIME-Version: 1.0 References: <3da88930-439c-1892-29b4-4977ddbb0b0a@redhat.com> <07a81543-c262-f153-6414-3d967dde02b2@redhat.com> <9157bf00-299f-993d-dd16-62f13e017a3f@redhat.com> <87o8byqpao.fsf@toke.dk> <87im26qn9q.fsf@toke.dk> <965bb2c1-64c5-eeb2-6f35-52dd2652d1be@redhat.com> In-Reply-To: <965bb2c1-64c5-eeb2-6f35-52dd2652d1be@redhat.com> From: Yuri Benditovich Date: Mon, 28 Jun 2021 14:18:23 +0300 Message-ID: Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd. To: Jason Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: none client-ip=2607:f8b0:4864:20::22b; envelope-from=yuri.benditovich@daynix.com; helo=mail-oi1-x22b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew Melnichenko , =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , "Michael S . Tsirkin" , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Markus Armbruster , qemu-devel@nongnu.org, Yan Vugenfirer , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Jun 23, 2021 at 3:47 AM Jason Wang wrote: > > > =E5=9C=A8 2021/6/22 =E4=B8=8B=E5=8D=885:09, Toke H=C3=B8iland-J=C3=B8rgen= sen =E5=86=99=E9=81=93: > > Daniel P. Berrang=C3=A9 writes: > > > >> On Tue, Jun 22, 2021 at 10:25:19AM +0200, Toke H=C3=B8iland-J=C3=B8rge= nsen wrote: > >>> Jason Wang writes: > >>> > >>>> =E5=9C=A8 2021/6/22 =E4=B8=8A=E5=8D=8811:29, Yuri Benditovich =E5=86= =99=E9=81=93: > >>>>> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang w= rote: > >>>>>> =E5=9C=A8 2021/6/19 =E4=B8=8A=E5=8D=884:03, Andrew Melnichenko =E5= =86=99=E9=81=93: > >>>>>>> Hi Jason, > >>>>>>> I've checked "kernel.unprivileged_bpf_disabled=3D0" on Fedora, U= buntu, > >>>>>>> and Debian - no need permissions to update BPF maps. > >>>>>> How about RHEL :) ? > >>>>> If I'm not mistaken, the RHEL releases do not use modern kernels ye= t > >>>>> (for BPF we need 5.8+). > >>>>> So this will be (probably) relevant for RHEL 9. Please correct me i= f I'm wrong. > >>>> Adding Toke for more ideas on this. > >>> Ignore the kernel version number; we backport all of BPF to RHEL, > >>> basically. RHEL8.4 is up to upstream kernel 5.10, feature-wise. > >>> > >>> However, we completely disable unprivileged BPF on RHEL kernels. Also= , > >>> there's upstream commit: > >>> 08389d888287 ("bpf: Add kconfig knob for disabling unpriv bpf by defa= ult") > >>> > >>> which adds a new value of '2' to the unprivileged_bpf_disable sysctl.= I > >>> believe this may end up being the default on Fedora as well. > >>> > >>> So any design relying on unprivileged BPF is likely to break; I'd > >>> suggest you look into how you can get this to work with CAP_BPF :) > >> QEMU will never have any capabilities. Any resources that required > >> privileges have to be opened by a separate privileged helper, and the > >> open FD then passed across to the QEMU process. This relies on the > >> capabilities checks only being performed at time of initial opening, > >> and *not* on operations performed on the already open FD. > > That won't work for regular map updates either, unfortunately: you stil= l > > have to perform a bpf() syscall to update an element, and that is a > > privileged operation. > > > > You may be able to get around this by using an array map type and > > mmap()'ing the map contents, but I'm not sure how well that will work > > across process boundaries. > > > > If it doesn't, I only see two possibilities: populate the map > > ahead-of-time and leave it in place, or keep the privileged helper > > process around to perform map updates on behalf of QEMU... > > > Right, and this could be probably done by extending and tracking the RSS > update via rx filter event. Jason, Can you please get a little into details - what you mean by 'extending and tracking the RSS > update via rx filter event'? Thanks, Yuri > > Thanks > > > > > > -Toke > > >