On Tue, Feb 6, 2024 at 12:55 AM Andrew Melnychenko <and...@daynix.com> wrote: > > 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-and...@daynix.com/ > > Signed-off-by: Andrew Melnychenko <and...@daynix.com> > --- > ebpf/ebpf.c | 69 +++++++++++++++++++++++++++++++++++++++++++
Let's add ebpf.c to MAINTAINERS otherwise CI may warn like: https://gitlab.com/jasowang/qemu/-/jobs/6349138969 Thanks
