Re: [PATCH] ebpf: fix compatibility with libbpf 1.0+

[Andrew Melnichenko]

Hi, all.
In the future, there would be eBPF RSS + the helper for Libvirt interaction.
And those patches are required for future work. Technically they are
required for the current builds with linked libbpf 1.01.
Can we apply this patch?


On Wed, Dec 28, 2022 at 6:19 PM Andrew Melnichenko <andrew@daynix.com> wrote:
>
> Hi, it's a good idea to update the skeleton generation. Technically
> skeleton generation is not a part of Qemu building. The skeleton is
> already presented in the Qemu tree, so we skip dependencies from
> clang/bpftool.
> It's a good idea to have an updated bpf program and simplified
> Makefile with Qemu sources. And the skeleton in the Qemu tree should
> be identical to what the Makefile.ebpf would generate.
> I think having one patch with all changes to eBPF RSS is acceptable.
>
> On Tue, Dec 20, 2022 at 6:30 PM Shreesh Adiga
> <16567adigashreesh@gmail.com> wrote:
> >
> > On Sun, Dec 18, 2022 at 05:15:04PM +0100, Philippe Mathieu-Daudé wrote:
> > > Hi,
> > >
> > > On 18/12/22 15:39, Shreesh Adiga wrote:
> > > > The current implementation fails to load on a system with
> > > > libbpf 1.0 and reports that legacy map definitions in 'maps'
> > > > section are not supported by libbpf v1.0+. This commit updates
> > > > the Makefile to add BTF (-g flag) and appropriately updates
> > > > the maps in rss.bpf.c and update the skeleton file in repo.
> > > >
> > > > Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
> > > > ---
> > > >   ebpf/rss.bpf.skeleton.h  | 1171 ++++++++++++++++++++++++++++----------
> > > >   tools/ebpf/Makefile.ebpf |    8 +-
> > > >   tools/ebpf/rss.bpf.c     |   43 +-
> > > >   3 files changed, 891 insertions(+), 331 deletions(-)
> > >
> > >
> > > > +static inline const void *rss_bpf__elf_bytes(size_t *sz)
> > > > +{
> > > > +   *sz = 20440;
> > > > +   return (const void *)"\
> > > >   
> > > > \x7f\x45\x4c\x46\x02\x01\x01\0\0\0\0\0\0\0\0\0\x01\0\xf7\0\x01\0\0\0\0\0\0\0\0\
> > > > -\0\0\0\0\0\0\0\0\0\0\0\x18\x1d\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0a\0\
> > > > -\x01\0\xbf\x18\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x4c\xff\0\0\0\0\xbf\xa7\
> > > > -\0\0\0\0\0\0\x07\x07\0\0\x4c\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
> > > > +\0\0\0\0\0\0\0\0\0\0\0\x98\x4c\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x0d\0\
> > > > +\x01\0\xbf\x19\0\0\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\x54\xff\0\0\0\0\xbf\xa7\
> > > > +\0\0\0\0\0\0\x07\x07\0\0\x54\xff\xff\xff\x18\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
> > > >   
> > > > \xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x06\0\0\0\0\0\0\x18\x01\0\0\0\0\0\
> > > > -\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x07\0\0\0\0\0\0\
> > > > -\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x66\x02\0\0\0\0\xbf\x79\0\0\
> > > > -\0\0\0\0\x15\x09\x64\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
> > > > -\0\x5d\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc0\xff\0\0\0\0\x7b\x1a\xb8\xff\
> > > > -\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\0\x7b\x1a\xa0\xff\0\0\0\
> > > > -\0\x63\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\x1a\x88\xff\0\0\0\0\x7b\
> > > > -\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\x70\xff\0\0\0\0\x7b\x1a\
> > > > -\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\xff\0\0\0\0\x7b\x1a\x50\
> > > > -\xff\0\0\0\0\x15\x08\x4c\x02\0\0\0\0\x6b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
> > > > -\0\x07\x03\0\0\xd0\xff\xff\xff\xbf\x81\0\0\0\0\0\0\xb7\x02\0\0\x0c\0\0\0\xb7\
> > > > +\0\0\0\0\0\0\0\0\0\xbf\x72\0\0\0\0\0\0\x85\0\0\0\x01\0\0\0\xbf\x08\0\0\0\0\0\0\
> > > > +\x18\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\x15\x06\x67\x02\0\0\0\0\xbf\x87\0\0\
> > > > +\0\0\0\0\x15\x07\x65\x02\0\0\0\0\x71\x61\0\0\0\0\0\0\x55\x01\x01\0\0\0\0\0\x05\
> > > > +\0\x5e\x02\0\0\0\0\xb7\x01\0\0\0\0\0\0\x63\x1a\xc8\xff\0\0\0\0\x7b\x1a\xc0\xff\
> > > > +\0\0\0\0\x7b\x1a\xb8\xff\0\0\0\0\x7b\x1a\xb0\xff\0\0\0\0\x7b\x1a\xa8\xff\0\0\0\
> > > > +\0\x63\x1a\xa0\xff\0\0\0\0\x7b\x1a\x98\xff\0\0\0\0\x7b\x1a\x90\xff\0\0\0\0\x7b\
> > > > +\x1a\x88\xff\0\0\0\0\x7b\x1a\x80\xff\0\0\0\0\x7b\x1a\x78\xff\0\0\0\0\x7b\x1a\
> > > > +\x70\xff\0\0\0\0\x7b\x1a\x68\xff\0\0\0\0\x7b\x1a\x60\xff\0\0\0\0\x7b\x1a\x58\
> > > > +\xff\0\0\0\0\x15\x09\x4d\x02\0\0\0\0\x6b\x1a\xd0\xff\0\0\0\0\xbf\xa3\0\0\0\0\0\
> > > [...]
> > >
> > > Can we have a build system step which generates this file and compare
> > > with what is committed in the repository that we can run in our CI?
> > >
> > > That would avoid the need of human review of this blob.
> > >
> > Here are the steps to verify:
> > Pull latest archlinux/archlinux docker image and get a bash shell inside
> > the container. Install the required toolchain packages.
> > pacman -Syu --noconfirm
> > pacman -S --noconfirm  bpf libbpf llvm clang make
> >
> > Confirm the versions:
> > clang 14.0.6
> > bpftool 7.0.0
> > libbpf 1.0.1
> >
> > After this, ensure that the files Makefile.ebpf and rss.bpf.c from this
> > patch exist at /home/shreesh/c/qemu/tools/ebpf/ inside the docker.
> > This path seems to be important since BTF info seems to contain the absolute
> > path of rss.bpf.c which was compiled by clang and is embedded inside
> > the generated ELF object.
> >
> > Run `make -C /home/shreesh/c/qemu/tools/ebpf -f Makefile.ebpf` and
> > verify that `sha256sum /home/shreesh/c/qemu/tools/ebpf/rss.bpf.skeleton.h` 
> > is
> > a54af3d1fb401ddd56c151f00ae20d6557e965c0a1a4d8ed5f8d925457158a0e which
> > should be the same as the one submitted as part of this patch.
> >
> > I'm not familiar with QEMU's CI and am not sure if the above steps can
> > be converted into build system steps. However it should be doable by a
> > human and verify that the generated skeleton file is correct and not
> > tampered with.
> >
> > Regards,
> > Shreesh