From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51556 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PI1ce-0006Nb-BN for qemu-devel@nongnu.org; Mon, 15 Nov 2010 11:09:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PI1cc-0006dm-KU for qemu-devel@nongnu.org; Mon, 15 Nov 2010 11:09:35 -0500 Received: from mail-qy0-f180.google.com ([209.85.216.180]:53875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PI1cc-0006dK-IG for qemu-devel@nongnu.org; Mon, 15 Nov 2010 11:09:34 -0500 Received: by qyk36 with SMTP id 36so2343398qyk.4 for ; Mon, 15 Nov 2010 08:09:33 -0800 (PST) Message-ID: <4CE15B39.5070207@codemonkey.ws> Date: Mon, 15 Nov 2010 10:09:29 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20101104180406.GA2820@redhat.com> <5f91d600c749e66de107f60298c5ebd36645beff.1288892774.git.mst@redhat.com> <4CE149CB.1040301@codemonkey.ws> <20101115151817.GA30509@redhat.com> In-Reply-To: <20101115151817.GA30509@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, Juan Quintela On 11/15/2010 09:18 AM, Michael S. Tsirkin wrote: > 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. > They are separate. For instance, we don't rely on stop to pause pending disk I/O because we don't serialize pending disk I/O operations. Instead, we flush all pending I/O and rely on the fact that disk I/O requests are always submitted in the context of a vCPU operation. This assumption breaks down though with ioeventfd so we need to revisit it. > 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? > I agree it's a problem but I'm not sure that just marking fd handlers really helps. Bottom halves can also trigger transmits. I think that if we put something in the network layer that just queued packets if the vm is stopped, it would be a more robust solution to the problem. > 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? > If you suppress any I/O then the memory changes don't matter because the same changes will happen on the destination too. I think this basic problem is the same as Kemari. We can either attempt to totally freeze a guest which means stopping all callbacks that are device related or we can prevent I/O from happening which should introduce enough determinism to fix the problem in practice. Regards, Anthony Liguori