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

[Andrew Melnichenko]

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