On Wed, Oct 27, 2021 at 03:47:18AM -0300, Leonardo Bras Soares Passos wrote: > On Wed, Oct 13, 2021 at 3:24 AM Peter Xu <pet...@redhat.com> wrote: > > > > On Sat, Oct 09, 2021 at 04:56:13AM -0300, Leonardo Bras wrote: > > > diff --git a/qapi/migration.json b/qapi/migration.json > > > index 88f07baedd..c4890cbb54 100644 > > > --- a/qapi/migration.json > > > +++ b/qapi/migration.json > > > @@ -724,6 +724,11 @@ > > > # will consume more CPU. > > > # Defaults to 1. (Since 5.0) > > > # > > > +# @multifd-zerocopy: Controls behavior on sending memory pages on > > > multifd migration. > > > +# When true, enables a zerocopy mechanism for sending > > > memory > > > +# pages, if host does support it. > > > +# Defaults to false. (Since 6.2) > > > +# > > > > Shall we keep it named "@zerocopy"? Yes we have that dependency with > > multifd, > > but it's fine to just fail the configuration if multifd not set. The thing > > is > > we don't know whether that dependency will last forever, and we probably > > don't > > want to introduce yet another feature bit when we can remove the > > dependency.. > > as we can't remove the old one to be compatible. > > It makes sense not wanting to create a new future bit in the future, > but if we just add a > "@zerocopy' , wouldn't we need to fail every migration setup that > don't support zerocopy? > > (Thinking back, to stay as it is, it would also be necessary that I > find a way to fail other multifd setups that don't support zerocopy, > for v5)
Yes I think so; imho we can fail either whey applying the bit, or it's okay too to fail at the start of migration. Thanks, -- Peter Xu
