qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] qmp: Added the helper stamp check.


From: Yuri Benditovich
Subject: Re: [PATCH 3/5] qmp: Added the helper stamp check.
Date: Tue, 28 Feb 2023 11:56:27 +0200

On Mon, Feb 20, 2023 at 11:50 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Sun, Feb 19, 2023 at 06:20:58PM +0200, Andrew Melnychenko wrote:
> Added a function to check the stamp in the helper.
> eBPF helper should have a special symbol that generates during the build.
> QEMU checks the helper and determines that it fits, so the helper
> will produce proper output.

I think this is quite limiting for in place upgrades.

Consider this scenario

 * Host has QEMU 8.1.0 installed
 * VM is running QEMU 8.1.0
 * QEMU 8.1.1 is released with a bug fix in the EBF program
 * Host is upgraded to QEMU 8.1.1
 * User attempts to hotplug a NIC to the running VM

IIUC this last step is going to fail because we'll be loading
the EBF program from 8.1.1 and so its hash is different from
that expected by the QEMU 8.1.0 that the pre-existing VM is
running.

  Indeed we did not take in account the in-place upgrade.

 
If some changes to the EBF program are not going to be back
compatible from the POV of the QEMU process, should we instead
be versioning the EBF program. eg so new QEMU will ship both
the old and new versions of the EBF program.


This does not seem to be an elegant option: QEMU theoretically can include different eBPF programs but it hardly can interface with each one of them.
The code of QEMU (access to eBPF maps etc) includes header files which eBPF of the day is being built with them.

I see 2 options to address this issue (of course there are more)
1. Build and install qemu-rss-helper-<hash> executable. Libvirt will always have a correct name, so for the running instance it will use qemu-rss-helper-<old-hash>, for the new instance it will use  qemu-rss-helper-<new-hash>
2. Build the helper executable and link it inside qemu as a blob. Libvirt will always retrieve the executable to the temporary file name and use it. So the retrieved helper will always be compatible with QEMU. I'm not sure what is the most portable way to do that.

Daniel,
Does one of these seem suitable?


With regards,
Daniel
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


reply via email to

[Prev in Thread] Current Thread [Next in Thread]