mirror of
https://gitlab.com/qemu-project/qemu
synced 2024-07-21 10:24:33 +00:00
e88899fa90
Now, the binary objects may be retrieved by id. It would require for future qmp commands that may require specific eBPF blob. Added command "request-ebpf". This command returns eBPF program encoded base64. The program taken from the skeleton and essentially is an ELF object that can be loaded in the future with libbpf. The reason to use the command to provide the eBPF object instead of a separate artifact was to avoid issues related to finding the eBPF itself. eBPF object is an ELF binary that contains the eBPF program and eBPF map description(BTF). Overall, eBPF object should contain the program and enough metadata to create/load eBPF with libbpf. As the eBPF maps/program should correspond to QEMU, the eBPF can't be used from different QEMU build. The first solution was a helper that comes with QEMU and loads appropriate eBPF objects. And the issue is to find a proper helper if the system has several different QEMUs installed and/or built from the source, which helpers may not be compatible. Another issue is QEMU updating while there is a running QEMU instance. With an updated helper, it may not be possible to hotplug virtio-net device to the already running QEMU. Overall, requesting the eBPF object from QEMU itself solves possible failures with acceptable effort. Links: [PATCH 3/5] qmp: Added the helper stamp check. https://lore.kernel.org/all/20230219162100.174318-4-andrew@daynix.com/ Signed-off-by: Andrew Melnychenko <andrew@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
67 lines
1.6 KiB
Python
67 lines
1.6 KiB
Python
# -*- Mode: Python -*-
|
|
# vim: filetype=python
|
|
#
|
|
# This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
# See the COPYING file in the top-level directory.
|
|
|
|
##
|
|
# = eBPF Objects
|
|
#
|
|
# eBPF object is an ELF binary that contains the eBPF
|
|
# program and eBPF map description(BTF). Overall, eBPF
|
|
# object should contain the program and enough metadata
|
|
# to create/load eBPF with libbpf. As the eBPF maps/program
|
|
# should correspond to QEMU, the eBPF can't be used from
|
|
# different QEMU build.
|
|
#
|
|
# Currently, there is a possible eBPF for receive-side scaling (RSS).
|
|
#
|
|
##
|
|
|
|
##
|
|
# @EbpfObject:
|
|
#
|
|
# An eBPF ELF object.
|
|
#
|
|
# @object: the eBPF object encoded in base64
|
|
#
|
|
# Since: 9.0
|
|
##
|
|
{ 'struct': 'EbpfObject',
|
|
'data': {'object': 'str'},
|
|
'if': 'CONFIG_EBPF' }
|
|
|
|
##
|
|
# @EbpfProgramID:
|
|
#
|
|
# The eBPF programs that can be gotten with request-ebpf.
|
|
#
|
|
# @rss: Receive side scaling, technology that allows steering traffic
|
|
# between queues by calculation hash. Users may set up
|
|
# indirection table and hash/packet types configurations. Used
|
|
# with virtio-net.
|
|
#
|
|
# Since: 9.0
|
|
##
|
|
{ 'enum': 'EbpfProgramID',
|
|
'if': 'CONFIG_EBPF',
|
|
'data': [ { 'name': 'rss' } ] }
|
|
|
|
##
|
|
# @request-ebpf:
|
|
#
|
|
# Retrieve an eBPF object that can be loaded with libbpf. Management
|
|
# applications (g.e. libvirt) may load it and pass file descriptors to
|
|
# QEMU, so they can run running QEMU without BPF capabilities.
|
|
#
|
|
# @id: The ID of the program to return.
|
|
#
|
|
# Returns: eBPF object encoded in base64.
|
|
#
|
|
# Since: 9.0
|
|
##
|
|
{ 'command': 'request-ebpf',
|
|
'data': { 'id': 'EbpfProgramID' },
|
|
'returns': 'EbpfObject',
|
|
'if': 'CONFIG_EBPF' }
|