Re: [PATCH 5/5] qmp: Added qemu-ebpf-rss-path command.

[Andrew Melnichenko <andrew@daynix.com>]

[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 5495 bytes --]