From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhHLe-0004g8-6k for qemu-devel@nongnu.org; Thu, 23 Oct 2014 08:18:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhHLY-0003R4-1g for qemu-devel@nongnu.org; Thu, 23 Oct 2014 08:18:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhHLX-0003Qb-QR for qemu-devel@nongnu.org; Thu, 23 Oct 2014 08:18:27 -0400 Date: Thu, 23 Oct 2014 13:18:11 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20141023121810.GC7659@work-vm> References: <1412358473-31398-1-git-send-email-dgilbert@redhat.com> <1412358473-31398-47-git-send-email-dgilbert@redhat.com> <54303394.1050008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54303394.1050008@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 46/47] postcopy: Wire up loadvm_postcopy_ram_handle_{run, end} commands List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aarcange@redhat.com, yamahata@private.email.ne.jp, lilei@linux.vnet.ibm.com, quintela@redhat.com, cristian.klein@cs.umu.se, qemu-devel@nongnu.org, amit.shah@redhat.com, yanghy@cn.fujitsu.com * Paolo Bonzini (pbonzini@redhat.com) 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 / dgilbert@redhat.com / Manchester, UK