On 4/9/2025 12:22 PM, Vladimir Sementsov-Ogievskiy wrote:
On 15.01.25 22:00, Steve Sistare wrote:
This patch series implements a minimal version of cpr-transfer. Additional
series are ready to be posted to deliver the complete vision described
above, including
* vfio
* chardev
* vhost and tap
* blockers
* cpr-exec mode
Hi Steve. First, great congratulations with finally landed cpr-transfer! I saw
the history of Live Update series was started overly five years ago.
Thanks! It's been a marathon, not a sprint.
I've some questions, hope it's not much trouble for you.
1. We consider porting cpr-transver + vfio part of your "Live update: vfio and iommufd" to our
downstream QEMU, based on v7.2. What do you think? I mean, may be you may quickly answer "don't try,
you'll have to bring more than 100 commits from different series", or visa-versa "we have
downstream based on 7.2 too, so it's possible" (OK, seems the latter answer is not possible, as iommufd
code just absent in v7.2).
I have not tried it, but I think this is feasible if you omit the iommufd
patches.
You will also need some of the cpr-reboot patches (like mode-specific migration
blockers) which did not appear until qemu 8.2.
2. About cpr-exec. Do you plan resending it in future? The solution is interesting for us, as it simplifies management a lot.
I agree! I made that argument when I submitted it. Perhaps your +1 will add
enough critical mass to get it accepted next time. I do plan to resubmit it
later.
I read the discussion on cpr-exec, seems the main problem was the security
constraint, that we don't want to allow exec call in seccomp profile. Didn't
you consider a variant with loding the library instead of exec?
I mean:
- turn the whole QEMU into library, which may be dynamically loaded. Recently
there was a question how to do it, and the answer contained an example patch:
https://github.com/pbo-linaro/qemu/commit/fbb39cc64f77d4bf1e5e50795c75b62735bf5c5f
- and make a simple wrapper process for that library, which also is a container
for migration state (including file descriptors), during live update.
Benefits:
- no execve, and we just need to add pattern for "qemu library" paths to
apparmor profile
- probably, we can load new library _before_ starting the migration, reducing
freeze-time of migration - more like migration with two processes
I have not considered that. A colleague suggested something similar -- loading
the
new qemu binary in memory and implementing exec in userland. No doubt either
method would be a non-trivial amount of work, versus cpr-exec which already
works :)
Personally I don't think that requiring exec is a show stopper. If qemu is
deployed in
a container environment, then the potential targets of an exec can be limited
by the
container walls.
- Steve
