qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 46/47] postcopy: Wire up loadvm_postcopy_ram_


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 46/47] postcopy: Wire up loadvm_postcopy_ram_handle_{run, end} commands
Date: Thu, 23 Oct 2014 13:18:11 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Paolo Bonzini (address@hidden) wrote:
> Il 03/10/2014 19:47, Dr. David Alan Gilbert (git) ha scritto:
> > +        bool one_message = false;
> > +        /* This looks good, but it's possible that the device loading in 
> > the
> > +         * main thread hasn't finished yet, and so we might not be in 'RUN'
> > +         * state yet.
> > +         * TODO: Using an atomic_xchg or something for this
> 
> This looks like a good match for QemuEvent.  Or just mutex & condvar.

Done, QemuEvent seems to work nicely.

> 
> > +         */
> > +        while (mis->postcopy_ram_state == POSTCOPY_RAM_INCOMING_LISTENING) 
> > {
> 
> What if we had postcopy of something else than RAM?  Can you remove the
> "ram" part from the symbols that do not directly deal with RAM but just
> with the protocol?

Done; that's 'postcopy_state' and 'POSTCOPY_INCOMING_LISTENING'
a lot of the internal command enums have also lost the 'RAM'; but not
all of them (hopefully just the ones where it makes sense). Similarly
the loadvm_postcopy_ram_handle's are now loadvm_postcopy_handle_...

I've kept the hmp/qmp command with the 'ram'.

Dave

> Paolo
> 
> > +            if (!one_message) {
> > +                DPRINTF("%s: Waiting for RUN", __func__);
> > +                one_message = true;
> > +            }
> > +        }
> > +    }
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]