Re: [PATCH v7 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Wei Wang <wei.w.wang@intel.com>]

On 06/07/2018 02:32 PM, Peter Xu wrote:
> > > > Btw, the migration_state_notifiers is already there, but seems not really
> > > > used (I only tracked spice-core.c called
> > > > add_migration_state_change_notifier). I thought adding new migration states
> > > > can reuse all that we have.
> > > > What's your real concern about that? (not sure how defining new events would
> > > > make a difference)
> > > Migration state is exposed via control path (QMP).  Adding new states
> > > mean that the QMP clients will see more.  IMO that's not really
> > > anything that a QMP client will need to know, instead we can keep it
> > > internally.  That's a reason from compatibility pov.
> > >
> > > Meanwhile, it's not really a state-thing at all for me.  It looks
> > > really more like hook or event (start/stop of sync).
> > Thanks for sharing your concerns in detail, which are quite helpful for the
> > discussion. To reuse 99a0db9b, we can also add sub-states (or say events),
> > instead of new migration states.
> > For example, we can still define "enum RamSaveState" as above, which can be
> > an indication for the notifier queued on the 99a0db9b notider_list to decide
> > whether to call start or stop.
> > Does this solve your concern?
> Frankly speaking I don't fully understand how you would add that
> sub-state.  If you are confident with the idea, maybe you can post
> your new version with the change, then I can read the code.

Reusing 99a0db9b functions well, but I find it is more clear to let ram 
save state have it's own notifier list..will show how that works in v8.

Best,
Wei