On 8/15/2024 4:28 PM, Peter Xu wrote:
On Sat, Jul 20, 2024 at 04:07:50PM -0400, Steven Sistare wrote:The new user-visible interfaces are: * cpr-transfer (MigMode migration parameter) * cpr-uri (migration parameter)I wonder whether this parameter can be avoided already, maybe we can let cpr-transfer depend on unix socket in -incoming, then integrate fd sharing in the same channel?You saw the answer in another thread, but I repeat it here for others benefit: "CPR state cannot be sent over the normal migration channel, because devices and backends are created prior to reading the channel, so this mode sends CPR state over a second migration channel that is not visible to the user. New QEMU reads the second channel prior to creating devices or backends."Today when looking again, I wonder about the other way round: can we make the new parameter called "-incoming-cpr", working exactly the same as "cpr-uri" qemu cmdline, but then after cpr is loaded it'll be automatically be reused for migration incoming ports? After all, cpr needs to happen already with unix sockets. Having separate cmdline options grants user to make the other one to be non-unix, but that doesn't seem to buy us anything.. then it seems easier to always reuse it, and restrict cpr-transfer to only work with unix sockets for incoming too?
This idea also occurred to me, but I dislike the loss of flexibility for the incoming socket type. The exec URI in particular can do anything, and we would be eliminating it. I also think -incoming-cpr has equal or greater "specification complexity" than -cpr-uri. They both add a new option, and the former also modifies the behavior of an existing option (disallows it and subsumes it). - Steve
