qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd.


From: Jason Wang
Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd.
Date: Fri, 11 Jun 2021 13:36:15 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0


在 2021/6/10 下午2:55, Yuri Benditovich 写道:
On Thu, Jun 10, 2021 at 9:41 AM Jason Wang<jasowang@redhat.com>  wrote:
在 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.
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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]