From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55946 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI0pG-0003zL-Ks for qemu-devel@nongnu.org; Mon, 15 Nov 2010 10:18:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI0pE-0002sf-2Q for qemu-devel@nongnu.org; Mon, 15 Nov 2010 10:18:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI0pD-0002sL-Rb for qemu-devel@nongnu.org; Mon, 15 Nov 2010 10:18:32 -0500 Date: Mon, 15 Nov 2010 17:18:17 +0200 From: "Michael S. Tsirkin" Message-ID: <20101115151817.GA30509@redhat.com> References: <20101104180406.GA2820@redhat.com> <5f91d600c749e66de107f60298c5ebd36645beff.1288892774.git.mst@redhat.com> <4CE149CB.1040301@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE149CB.1040301@codemonkey.ws> Subject: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Juan Quintela On Mon, Nov 15, 2010 at 08:55:07AM -0600, Anthony Liguori wrote: > On 11/15/2010 08:52 AM, Juan Quintela wrote: > >"Michael S. Tsirkin" wrote: > >>There's no reason for tap to run when VM is stopped. > >>If we let it, it confuses the bridge on TX > >>and corrupts DMA memory on RX. > >> > >>Signed-off-by: Michael S. Tsirkin > >once here, what handlers make sense to run while stopped? > >/me can think of the normal console, non live migration, loadvm and not > >much more. Perhaps it is easier to just move the other way around? > > I'm not sure I concur that this is really a problem. > Semantically, I don't think that stop has to imply that the guest > memory no longer changes. > > Regards, > > Anthony Liguori > > >Later, Juan. Well, I do not really know about vmstop that is not for migration. For most vmstop calls are for migration. And there, the problems are very real. First, it's not just memory. At least for network transmit, sending out packets with the same MAC from two locations is a problem. See? For memory, it is much worse: any memory changes can either get discarded or not. This breaks consistency guarantees that guest relies upon. Imagine virtio index getting updated but content not being updated. See? -- MST