Re: [PATCH v2 5/6] qmp: Added new command to retrieve eBPF blob.

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, May 16, 2023 at 05:06:24PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > On Tue, May 16, 2023 at 04:04:39PM +0200, Markus Armbruster wrote:

[...]

>> >> However, I now wonder why we fetch it from QEMU.  Why not ship it with
>> >> QEMU?
>> >
>> > Fetching it from QEMU gives us a strong guarantee that the eBPF
>> > code actually matches the QEMU binary we're talking to, which is
>> > useful if you're dealing with RPMs which can be upgraded behind
>> > your back, or have multiple parallel installs of QEMU.
>> 
>> Yes, but what makes this one different from all the other things that
>> need to match?
>
> Many of the external resources QEMU uses don't need to be a precise
> match to a QEMU version, it is sufficient for them to be of "version
> X or newer".  eBPF programs need to be a precise match, because the
> QEMU code has assumptions about the eBPF code it uses, such as the
> configuration maps present.
>
> There is another example where a perfect match is needed - loadable
> .so modules. eg if you're running QEMU and trigger dlopen of a QEMU
> module, the loaded module needs to come from the perfect matching
> build. Most distros don't solve that, but there was something added
> a while back that let QEMU load modules from a specific location.
>
> The idea was that the RPM/Deb package manager can upgrade the
> modules, but the modules from the previously installed QEMU would be
> kept in somewhere temporary like /var/run/...., so that pre-existing
> running QEMU could still load the exact matched .sos. While that hack
> kinda works it has too many moving parts for my liking, leaving failure
> scenarios open. IMHO, being able to directly fetch the resource 
> directly from QEMU is a better strategy for eBPF programs, as it
> eliminates more of the failure scenarios with very little effort.

On the other hand, yet another way to solve the same class of problem.

If we decide that's what we want, the rationale needs to be worked into
the commit message.