From: Jason Wang <jasowang@redhat.com>
To: Andrew Melnychenko <andrew@daynix.com>,
mst@redhat.com, yuri.benditovich@daynix.com, armbru@redhat.com,
eblake@redhat.com, berrange@redhat.com
Cc: yan@daynix.com, qemu-devel@nongnu.org
Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd.
Date: Thu, 10 Jun 2021 14:41:09 +0800 [thread overview]
Message-ID: <f81de211-57f9-9319-9735-c6b964bbdc77@redhat.com> (raw)
In-Reply-To: <20210609100457.142570-1-andrew@daynix.com>
在 2021/6/9 下午6:04, Andrew Melnychenko 写道:
> 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 = 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 may
> have its own helper. That's why "query-helper-paths" qmp command
> was added. Qemu should return the path to the helper that suits
> 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.
Thanks
>
> Andrew Melnychenko (5):
> ebpf: Added eBPF initialization by fds.
> virtio-net: Added property to load eBPF RSS with fds.
> ebpf_rss_helper: Added helper for eBPF RSS.
> qmp: Added qemu-ebpf-rss-path command.
> meson: libbpf dependency now exclusively for Linux.
>
> ebpf/ebpf_rss-stub.c | 6 ++
> ebpf/ebpf_rss.c | 31 +++++++-
> ebpf/ebpf_rss.h | 5 ++
> ebpf/qemu-ebpf-rss-helper.c | 130 +++++++++++++++++++++++++++++++++
> hw/net/virtio-net.c | 77 ++++++++++++++++++-
> include/hw/virtio/virtio-net.h | 1 +
> meson.build | 37 ++++++----
> monitor/qmp-cmds.c | 78 ++++++++++++++++++++
> qapi/misc.json | 29 ++++++++
> 9 files changed, 374 insertions(+), 20 deletions(-)
> create mode 100644 ebpf/qemu-ebpf-rss-helper.c
>
next prev parent reply other threads:[~2021-06-10 6:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 10:04 [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd Andrew Melnychenko
2021-06-09 10:04 ` [RFC PATCH 1/5] ebpf: Added eBPF initialization by fds Andrew Melnychenko
2021-06-09 10:04 ` [RFC PATCH 2/5] virtio-net: Added property to load eBPF RSS with fds Andrew Melnychenko
2021-06-09 10:04 ` [RFC PATCH 3/5] ebpf_rss_helper: Added helper for eBPF RSS Andrew Melnychenko
2021-06-09 10:04 ` [RFC PATCH 4/5] qmp: Added qemu-ebpf-rss-path command Andrew Melnychenko
2021-06-11 14:15 ` Eric Blake
2021-06-11 17:21 ` Daniel P. Berrangé
2021-06-12 5:28 ` Markus Armbruster
2021-06-15 23:16 ` Andrew Melnichenko
2021-07-05 13:50 ` Andrew Melnichenko
2021-06-09 10:04 ` [RFC PATCH 5/5] meson: libbpf dependency now exclusively for Linux Andrew Melnychenko
2021-06-10 6:41 ` Jason Wang [this message]
2021-06-10 6:55 ` [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd Yuri Benditovich
2021-06-11 5:36 ` Jason Wang
2021-06-11 16:49 ` Andrew Melnichenko
2021-06-11 17:24 ` Daniel P. Berrangé
2021-06-15 9:13 ` Jason Wang
2021-06-15 22:18 ` Andrew Melnichenko
2021-06-18 20:03 ` Andrew Melnichenko
2021-06-21 9:20 ` Jason Wang
2021-06-22 3:29 ` Yuri Benditovich
2021-06-22 4:58 ` Jason Wang
2021-06-22 8:25 ` Toke Høiland-Jørgensen
2021-06-22 8:27 ` Daniel P. Berrangé
2021-06-22 9:09 ` Toke Høiland-Jørgensen
2021-06-22 13:01 ` Andrew Melnichenko
2021-06-22 13:17 ` Toke Høiland-Jørgensen
2021-06-23 0:47 ` Jason Wang
2021-06-28 11:18 ` Yuri Benditovich
2021-06-29 3:39 ` Jason Wang
2021-06-30 16:40 ` Andrew Melnichenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f81de211-57f9-9319-9735-c6b964bbdc77@redhat.com \
--to=jasowang@redhat.com \
--cc=andrew@daynix.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yan@daynix.com \
--cc=yuri.benditovich@daynix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).