Hi, > Ther first two are bogus. /work/armbru/tmp/inst-qemu/... is where "make > install" would put things. I last ran "make install" almost three > months ago. > The stamp check is implemented only for the RSS helper. Qemu looks for a helper first in HelpDir, then next to the binary. Bridge/PR helpers found in "inst-qemu" according to build configuration. To be more strict, for the next patch we may return only ebpf helper in the list. Other helpers may be added later with stamp check.
It's still unreliable in the sense of "may not > find the helper" > Ok, I see the problem. Here I can propose possible solutions: 1. Add the argument to QMP request - the path(s) where the qemu should look for helper by priority: argument path, installation dir, qemu's dir. And return an array of all possible helpers binaries. 2. Retrieve the stamp from QMP request, so Libvirt may check the stamp by itself. 3. Set suid bit to helper and pass the helper's path to the qemu, so qemu may run it by itself. Searching the ELF symbol table requires ELF. I suspect your meson.build > doesn't reflect that. > > It also requires the symbol table to be present. Statically linked > programs don't have one, if I remember correctly. > Well, qemu-ebpf-rss-helper is only for Linux and expectations are to have ELF binaries. The helper builds dynamically linked with libbpf.so at least. Management applications run qemu-system-FOO and helpers. They know > where to find qemu-system-FOO. It stands to reason that they also know > where to find the matching helpers. I fail to see why they need help > from qemu-system-FOO via QMP. Even if they need help, qemu-system-FOO > can't give it, because it cannot know for sure. It is wherever the > system administrator / distro put it. > We may have several different qemu builds which may require different rss helpers. Domain with a custom emulator: > > * <devices> > <emulator>/path_to_my_awesome_qemu_with_custom_bpf/qemu-system-FOO</emulator> > * > Libvirt would gather properties of that qemu and we need to provide the proper helper for it. The "default" helper from libvirt configure may not suit the qemu. So the idea is to ask the qemu itself where is a possible helper. So Libvirt may use only <emulator> without additional changes in XML document. So we need to solve next cases: - System admin or distributor places the qemu and helpers in InstallPath. Libvirt uses installed qemu and helpers. No hints from qemu are required. - Libvirt uses custom qemu <emulator>. Libvirt doesn't know where is the helper that was built with custom qemu. Qemu if finds the helper - verifies the stamp, to make sure. - Custom-built qemu is installed in the configured path(proper prefix etc.). Libvirt may use that emulator but don't know where is the helper - qemu knows and may provide a hint. There are much easier ways for that than searching through ELF symbol > tables. Have a command line option to print it. For qemu-system-FOO, > you can also have a QMP command to query it. > The stamp was added in a similar way as qemu modules(special symbol, checked during load). Also, checking the stamp without running is a good security measure. I get a few warnings. I'm copying the ones from Clang: > Thank you, I'll fix them in v2 patches with rebased tree.
