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=-5.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 350A3C48BDF for ; Fri, 18 Jun 2021 20:04:28 +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 9F1FE60FEE for ; Fri, 18 Jun 2021 20:04:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F1FE60FEE 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]:52986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1luKj4-0008BB-Cv for qemu-devel@archiver.kernel.org; Fri, 18 Jun 2021 16:04:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1luKhz-0007Mb-Oz for qemu-devel@nongnu.org; Fri, 18 Jun 2021 16:03:19 -0400 Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]:43882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1luKhw-000521-4l for qemu-devel@nongnu.org; Fri, 18 Jun 2021 16:03:19 -0400 Received: by mail-oi1-x232.google.com with SMTP id x196so11780452oif.10 for ; Fri, 18 Jun 2021 13:03:14 -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; bh=0XaXqYva/wHy/UtEltmeogV56guSl7cA7YcnQ/9TzXY=; b=g7o8yBL1N2S3tsyur9iUWHeYnww8Yv3yto5IlVH0cr4AvZ5/r66kuius6b4SEkue7m YzLXPWu2AZfio152yZLd4w1aPFSSxzrVQcEj4jm8yADdJ2u5t8lgnA71zfxYB9JBKyPY MKHcgmXBF4etasLXLJyiMIGDN6zATCqmw8DdWaNQCs50Q6N4gbQlDOUi8Angq+hXAAp2 P1Eb6/lWvi+rZQSjxO/i+0qpZlKI/VY62U0WOgegL42lnXq00737aDov6HEPMhvn6S7f Zw/HKtfObvGXk5JSKCUeTeW/+AeMr3GKSV/Al7piL8aX/0M2HIl8IfXoez1GGKsOIt7U ZaDg== 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=0XaXqYva/wHy/UtEltmeogV56guSl7cA7YcnQ/9TzXY=; b=DuRDvSoIGNEH4lHVOXShmYB+f/eR5wnILaVXRL0z6uqiHwI/tbkUaZAq88ttJNzkYt lpida3ZiRKG8JPOOlVKJqhfOjdsd0bS/+C7tDwmx4vwM/5o2XzsGNJBchensSNNMCmcY 4EE3VPbQHizFUAhU0zuVPpNDvtS0Pu4JSbQGMMkpUeRos+d1m8TPdLifg6vNIPS3CM6R jQWOifgJ15O84TqmM2WiRMRj/2X1ytCHX+jVaSO1KRp0UoCfVRLSDze/YxPhZRf6PYS+ RhUTfma/FSqscvz76voCsoADNDIBYWv5feyJs7u+oSmoibKGCbxZug62vSP7lXAzEnTl LSbQ== X-Gm-Message-State: AOAM530qJYKKX11k2qwMCQNxN6qU46KH/XYl+ULndVayd3mvRXKYupFC 2nVKfGkF0EulhgpauZoJZj2QwORut1Jdv7h8Qcl9ZA== X-Google-Smtp-Source: ABdhPJzmXaZjJOH5a8buOe4/1seiRzErJ1wRG2vuX3a7Ul82yRQgL0BmmrLbn8YIqipX1W5GJH/uc2dPHOOhNfoIP6U= X-Received: by 2002:aca:2215:: with SMTP id b21mr8511490oic.94.1624046593705; Fri, 18 Jun 2021 13:03:13 -0700 (PDT) MIME-Version: 1.0 References: <20210609100457.142570-1-andrew@daynix.com> <3da88930-439c-1892-29b4-4977ddbb0b0a@redhat.com> In-Reply-To: From: Andrew Melnichenko Date: Fri, 18 Jun 2021 23:03:02 +0300 Message-ID: Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd. To: Jason Wang Content-Type: multipart/alternative; boundary="000000000000511adb05c50fd05c" Received-SPF: none client-ip=2607:f8b0:4864:20::232; envelope-from=andrew@daynix.com; helo=mail-oi1-x232.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, HTML_MESSAGE=0.001, 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: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , "Michael S . Tsirkin" , qemu-devel@nongnu.org, Markus Armbruster , Yuri Benditovich , Yan Vugenfirer , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000511adb05c50fd05c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jason, I've checked "kernel.unprivileged_bpf_disabled=3D0" on Fedora, Ubuntu, and Debian - no need permissions to update BPF maps. On Wed, Jun 16, 2021 at 1:18 AM Andrew Melnichenko wrote: > Hi, > >> I may miss something. >> >> But RSS requires to update the map. This won't work if you don't grant >> any permission to qemu. >> >> Thanks >> > > Partly - with "kernel.unprivileged_bpf_disabled=3D0" capabilities is not > required to update maps. > With "kernel.unprivileged_bpf_disabled=3D1" - setting maps will fail(with= out > CAP_BPF) and "in-qemu" RSS will be used. > > On Tue, Jun 15, 2021 at 12:13 PM Jason Wang wrote: > >> >> =E5=9C=A8 2021/6/12 =E4=B8=8A=E5=8D=8812:49, Andrew Melnichenko =E5=86= =99=E9=81=93: >> > Hi, >> > >> > So I think the series is for unprivileged_bpf disabled. If I'm not >> > wrong, I guess the policy is to grant CAP_BPF but do fine grain >> > checks >> > via LSM. >> > >> > >> > The main idea is to run eBPF RSS with qemu without any permission. >> > Libvirt should handle everything and pass proper eBPF file descriptors= . >> > For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations) >> > also required, and in the future may be other permissions. >> >> >> I may miss something. >> >> But RSS requires to update the map. This won't work if you don't grant >> any permission to qemu. >> >> Thanks >> >> >> > >> > I'm not sure this is the best. We have several examples that let >> > libvirt >> > to involve. Examples: >> > >> > 1) create TAP device (and the TUN_SETIFF) >> > >> > 2) open vhost devices >> > >> > >> > Technically TAP/vhost not related to a particular qemu emulator. So >> common >> > TAP creation should fit any modern qemu. eBPF fds(program and maps) >> should >> > suit the interface for current qemu, g.e. some qemu builds may have >> > different map >> > structures or their count. It's necessary that the qemu got fds >> > prepared by the helper >> > that was built with the qemu. >> > >> > I think we need an example on the detail steps for how libvirt is >> > expected to use this. >> > >> > >> > The simplified workflow looks like this: >> > >> > 1. Libvirt got "emulator" from domain document. >> > 2. Libvirt queries for qemu capabilities. >> > 3. One of the capabilities is "qemu-ebpf-rss-helper" path(if present)= . >> > 4. On NIC preparation Libvirt checks for virtio-net + rss >> configurations. >> > 5. If required, the "qemu-ebpf-rss-helper" called and fds are >> > received through unix fd. >> > 6. Those fds are for eBPF RSS, which passed to child process - qemu. >> > 7. Qemu launched with virtio-net-pci property "rss" and "ebpf_rss_fds= ". >> > >> > >> > On Fri, Jun 11, 2021 at 8:36 AM Jason Wang > > > wrote: >> > >> > >> > =E5=9C=A8 2021/6/10 =E4=B8=8B=E5=8D=882:55, Yuri Benditovich =E5= =86=99=E9=81=93: >> > > On Thu, Jun 10, 2021 at 9:41 AM Jason Wang> > > wrote: >> > >> =E5=9C=A8 2021/6/9 =E4=B8=8B=E5=8D=886:04, Andrew Melnychenko = =E5=86=99=E9=81=93: >> > >>> Libvirt usually launches qemu with strict permissions. >> > >>> To enable eBPF RSS steering, qemu-ebpf-rss-helper was added. >> > >> A silly question: >> > >> >> > >> Kernel had the following permission checks in bpf syscall: >> > >> >> > >> if (sysctl_unprivileged_bpf_disabled && !bpf_capable()= ) >> > >> return -EPERM; >> > >> ... >> > >> >> > >> err =3D security_bpf(cmd, &attr, size); >> > >> if (err < 0) >> > >> return err; >> > >> >> > >> So if I understand the code correctly, bpf syscall can only be >> > done if: >> > >> >> > >> 1) unprivileged_bpf is enabled or >> > >> 2) has the capability and pass the LSM checks >> > >> >> > >> So I think the series is for unprivileged_bpf disabled. If I'm >> not >> > >> wrong, I guess the policy is to grant CAP_BPF but do fine grain >> > checks >> > >> via LSM. >> > >> >> > >> If this is correct, need to describe it in the commit log. >> > >> >> > >> >> > >>> Added property "ebpf_rss_fds" for "virtio-net" that allows to >> > >>> initialize eBPF RSS context with passed program & maps fds. >> > >>> >> > >>> Added qemu-ebpf-rss-helper - simple helper that loads eBPF >> > >>> context and passes fds through unix socket. >> > >>> Libvirt should call the helper and pass fds to qemu through >> > >>> "ebpf_rss_fds" property. >> > >>> >> > >>> Added explicit target OS check for libbpf dependency in meson. >> > >>> eBPF RSS works only with Linux TAP, so there is no reason to >> > >>> build eBPF loader/helper for non-Linux. >> > >>> >> > >>> Overall, libvirt process should not be aware of the "interface= " >> > >>> of eBPF RSS, it will not be aware of eBPF maps/program "type" >> and >> > >>> their quantity. >> > >> I'm not sure this is the best. We have several examples that >> > let libvirt >> > >> to involve. Examples: >> > >> >> > >> 1) create TAP device (and the TUN_SETIFF) >> > >> >> > >> 2) open vhost devices >> > >> >> > >> >> > >>> That's why qemu and the helper should be from >> > >>> the same build and be "synchronized". Technically each qemu ma= y >> > >>> have its own helper. That's why "query-helper-paths" qmp comma= nd >> > >>> was added. Qemu should return the path to the helper that suit= s >> > >>> and libvirt should use "that" helper for "that" emulator. >> > >>> >> > >>> qmp sample: >> > >>> C: { "execute": "query-helper-paths" } >> > >>> S: { "return": [ >> > >>> { >> > >>> "name": "qemu-ebpf-rss-helper", >> > >>> "path": "/usr/local/libexec/qemu-ebpf-rss-helper" >> > >>> } >> > >>> ] >> > >>> } >> > >> I think we need an example on the detail steps for how libvirt = is >> > >> expected to use this. >> > > The preliminary patches for libvirt are at >> > > https://github.com/daynix/libvirt/tree/RSSv1 >> > >> > >> > >> > Will have a look but it would be better if the assumption of the >> > management is detailed here to ease the reviewers. >> > >> > Thanks >> > >> > >> > > >> > >> >> --000000000000511adb05c50fd05c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jason,
I've checked "kernel.un= privileged_bpf_disabled=3D0" on Fedora,=C2=A0 Ubuntu, and Debian - no = need permissions to update BPF maps.

On Wed, Jun 16, 2021 at 1:18 AM A= ndrew Melnichenko <andrew@daynix.com> wrote:
Hi,
I may miss something.

But RSS requires to update the map. This won't work if you don't gr= ant
any permission to qemu.

Thanks

Partly - with "= ;kernel.unprivileged_bpf_disabled=3D0" capabilities is not required to= update maps.
With "kernel.unprivileged_bpf_disabled=3D1&quo= t; - setting maps will fail(without CAP_BPF) and "in-qemu" RSS wi= ll be used.

On Tue, Jun 15, 2021 at 12:13 PM Jason Wang <jasowang@redhat.com&= gt; wrote:

=E5=9C=A8 2021/6/12 =E4=B8=8A=E5=8D=8812:49, Andrew Melnichenko =E5=86=99= =E9=81=93:
> Hi,
>
>=C2=A0 =C2=A0 =C2=A0So I think the series is for unprivileged_bpf disab= led. If I'm not
>=C2=A0 =C2=A0 =C2=A0wrong, I guess the policy is to grant CAP_BPF but d= o fine grain
>=C2=A0 =C2=A0 =C2=A0checks
>=C2=A0 =C2=A0 =C2=A0via LSM.
>
>
> The main idea is to run eBPF RSS with qemu without any permission.
> Libvirt should handle everything and pass proper eBPF file descriptors= .
> For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations)
> also required, and in the future may be other permissions.


I may miss something.

But RSS requires to update the map. This won't work if you don't gr= ant
any permission to qemu.

Thanks


>
>=C2=A0 =C2=A0 =C2=A0I'm not sure this is the best. We have several = examples that let
>=C2=A0 =C2=A0 =C2=A0libvirt
>=C2=A0 =C2=A0 =C2=A0to involve. Examples:
>
>=C2=A0 =C2=A0 =C2=A01) create TAP device (and the TUN_SETIFF)
>
>=C2=A0 =C2=A0 =C2=A02) open vhost devices
>
>
> Technically TAP/vhost not related to a particular qemu emulator. So co= mmon
> TAP creation should fit any modern qemu. eBPF fds(program and maps) sh= ould
> suit the interface for current qemu, g.e. some qemu builds may have > different map
> structures or their count. It's necessary that the qemu got fds > prepared by the helper
> that was built with the qemu.
>
>=C2=A0 =C2=A0 =C2=A0I think we need an example on the detail steps for = how libvirt is
>=C2=A0 =C2=A0 =C2=A0expected to use this.
>
>
> The simplified workflow looks like this:
>
>=C2=A0 1. Libvirt got "emulator" from domain document.
>=C2=A0 2. Libvirt queries for qemu capabilities.
>=C2=A0 3. One of the capabilities is "qemu-ebpf-rss-helper" p= ath(if present).
>=C2=A0 4. On NIC preparation Libvirt checks for virtio-net + rss config= urations.
>=C2=A0 5. If required, the "qemu-ebpf-rss-helper" called and = fds are
>=C2=A0 =C2=A0 =C2=A0received through unix fd.
>=C2=A0 6. Those fds are for eBPF RSS, which passed to child process - q= emu.
>=C2=A0 7. Qemu launched with virtio-net-pci property "rss" an= d "ebpf_rss_fds".
>
>
> On Fri, Jun 11, 2021 at 8:36 AM Jason Wang <jasowang@redhat.com
> <mailto:ja= sowang@redhat.com>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0=E5=9C=A8 2021/6/10 =E4=B8=8B=E5=8D=882:55, Yuri Be= nditovich =E5=86=99=E9=81=93:
>=C2=A0 =C2=A0 =C2=A0> On Thu, Jun 10, 2021 at 9:41 AM Jason Wang<= jasowang@redhat.co= m
>=C2=A0 =C2=A0 =C2=A0<mailto:jasowang@redhat.com>>=C2=A0 wrote:
>=C2=A0 =C2=A0 =C2=A0>> =E5=9C=A8 2021/6/9 =E4=B8=8B=E5=8D=886:04,= Andrew Melnychenko =E5=86=99=E9=81=93:
>=C2=A0 =C2=A0 =C2=A0>>> Libvirt usually launches qemu with str= ict permissions.
>=C2=A0 =C2=A0 =C2=A0>>> To enable eBPF RSS steering, qemu-ebpf= -rss-helper was added.
>=C2=A0 =C2=A0 =C2=A0>> A silly question:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Kernel had the following permission checks= in bpf syscall:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (sysc= tl_unprivileged_bpf_disabled && !bpf_capable())
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0return -EPERM;
>=C2=A0 =C2=A0 =C2=A0>> ...
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0er= r =3D security_bpf(cmd, &attr, size);
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if= (err < 0)
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0return err;
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> So if I understand the code correctly, bpf= syscall can only be
>=C2=A0 =C2=A0 =C2=A0done if:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 1) unprivileged_bpf is enabled or
>=C2=A0 =C2=A0 =C2=A0>> 2) has the capability=C2=A0 and pass the L= SM checks
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> So I think the series is for unprivileged_= bpf disabled. If I'm not
>=C2=A0 =C2=A0 =C2=A0>> wrong, I guess the policy is to grant CAP_= BPF but do fine grain
>=C2=A0 =C2=A0 =C2=A0checks
>=C2=A0 =C2=A0 =C2=A0>> via LSM.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> If this is correct, need to describe it in= the commit log.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>> Added property "ebpf_rss_fds"= ; for "virtio-net" that allows to
>=C2=A0 =C2=A0 =C2=A0>>> initialize eBPF RSS context with passe= d program & maps fds.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Added qemu-ebpf-rss-helper - simple he= lper that loads eBPF
>=C2=A0 =C2=A0 =C2=A0>>> context and passes fds through unix so= cket.
>=C2=A0 =C2=A0 =C2=A0>>> Libvirt should call the helper and pas= s fds to qemu through
>=C2=A0 =C2=A0 =C2=A0>>> "ebpf_rss_fds" property.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Added explicit target OS check for lib= bpf dependency in meson.
>=C2=A0 =C2=A0 =C2=A0>>> eBPF RSS works only with Linux TAP, so= there is no reason to
>=C2=A0 =C2=A0 =C2=A0>>> build eBPF loader/helper for non-Linux= .
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> Overall, libvirt process should not be= aware of the "interface"
>=C2=A0 =C2=A0 =C2=A0>>> of eBPF RSS, it will not be aware of e= BPF maps/program "type" and
>=C2=A0 =C2=A0 =C2=A0>>> their quantity.
>=C2=A0 =C2=A0 =C2=A0>> I'm not sure this is the best. We have= several examples that
>=C2=A0 =C2=A0 =C2=A0let libvirt
>=C2=A0 =C2=A0 =C2=A0>> to involve. Examples:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 1) create TAP device (and the TUN_SETIFF)<= br> >=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 2) open vhost devices
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 That's why qemu and t= he helper should be from
>=C2=A0 =C2=A0 =C2=A0>>> the same build and be "synchroniz= ed". Technically each qemu may
>=C2=A0 =C2=A0 =C2=A0>>> have its own helper. That's why &q= uot;query-helper-paths" qmp command
>=C2=A0 =C2=A0 =C2=A0>>> was added. Qemu should return the path= to the helper that suits
>=C2=A0 =C2=A0 =C2=A0>>> and libvirt should use "that"= ; helper for "that" emulator.
>=C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0>>> qmp sample:
>=C2=A0 =C2=A0 =C2=A0>>> C: { "execute": "query-= helper-paths" }
>=C2=A0 =C2=A0 =C2=A0>>> S: { "return": [
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo= t;name": "qemu-ebpf-rss-helper",
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo= t;path": "/usr/local/libexec/qemu-ebpf-rss-helper"
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0]
>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0>> I think we need an example on the detail s= teps for how libvirt is
>=C2=A0 =C2=A0 =C2=A0>> expected to use this.
>=C2=A0 =C2=A0 =C2=A0> The preliminary patches for libvirt are at
>=C2=A0 =C2=A0 =C2=A0> https://github.com/daynix/l= ibvirt/tree/RSSv1
>=C2=A0 =C2=A0 =C2=A0<https://github.com/daynix/li= bvirt/tree/RSSv1>
>
>
>=C2=A0 =C2=A0 =C2=A0Will have a look but it would be better if the assu= mption of the
>=C2=A0 =C2=A0 =C2=A0management is detailed here to ease the reviewers.<= br> >
>=C2=A0 =C2=A0 =C2=A0Thanks
>
>
>=C2=A0 =C2=A0 =C2=A0>
>

--000000000000511adb05c50fd05c--