* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 30/03/2015 19:46, Dr. David Alan Gilbert wrote:
> >>> > > +PostcopyState postcopy_state_get(MigrationIncomingState *mis)
> >>> > > +{
> >>> > > + return atomic_fetch_add(&mis->postcopy_state, 0);
> >>> > > +}
> >>> > > +
> >>> > > +/* Set the state and return the old state */
> >>> > > +PostcopyState postcopy_state_set(MigrationIncomingState *mis,
> >>> > > + PostcopyState new_state)
> >>> > > +{
> >>> > > + return atomic_xchg(&mis->postcopy_state, new_state);
> >>> > > +}
> >> >
> >> > Which are the (multiple) threads are calling these functions?
> > The main thread receiving the migration and the postcopy ram_listen_thread
> > receiving the RAM pages.
> > It's not actually racy between multiple threads updating it,
> > it's sequenced so that the main thread initialises it and then
> > hands over to the listen thread that takes it over from that point.
>
> I would use atomic_mb_read/atomic_mb_set here.
The benefit of the atomic_xchg is that I get the old value back so
that I can sanity check I was in the state I thought I should have
been.
Dave
>
> Paolo
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
