Re: [Qemu-devel] [PATCH RFC 6/6] migration: enable return path for precopy

[Juan Quintela]

Peter Xu <address@hidden> wrote:

...

>> > Here what I wanted to achieve is that:
>> >
>> > a. for postcopy, we should try to enable return path, and it must
>> >    succeed
>> >
>> > b. for the case when enable_return_path is set, we try to enable return
>> >    path, but even if it failed, we can still continue
>> >
>> > Could we really achieve (b) if with above code? Or anything I missed?
>> 
>> if we enable_return_path -> it should success, otherwise it makes no
>> sense, no?  We can try to remove the return path for some transports if
>> needed, but it makes no sense to enable a property that means:
>> "please, pretty please, enable it if you can"
>
> (Indeed this is awkward... :)
>
>> 
>> if we are going to do it that way, then it is better to change the
>> property the other way around:
>> 
>> - disable_return_path: set for all old machine types
>> 
>> And not set for newer machine types, meaning that we just try.
>> 
>> What do you think?
>
> Both namings work for me.
>
> The problem is that we cannot really force this as long as there is
> any type of transports that does not support return path. E.g., when
> migrating to an "exec:" typed transport with single-out IO stream. In
> that case, if we fail the migration, it'll break the old behavior,
> right? Then for exec: typed users they need to manually provide
> enable_return_path=false to finally allow them to migrate.
>
> (I think that's the most tricky point of this series...)

Then do what I said.  Disable it for old machine types.
And for new machine types, we just try our best.  What I object is
having a property with a meaning of "perhaps enable return path".

And yes, representing with a boolean a tri-state is tricky O:-)

Later, Juan.