From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54683 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PI63U-0005eQ-Ng
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 15:53:59 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1PI638-00088q-Ak
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 15:53:36 -0500
Received: from mail-qw0-f45.google.com ([209.85.216.45]:33749)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1PI638-00088i-7g
	for qemu-devel@nongnu.org; Mon, 15 Nov 2010 15:53:14 -0500
Received: by qwd7 with SMTP id 7so35983qwd.4
	for <qemu-devel@nongnu.org>; Mon, 15 Nov 2010 12:53:13 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <4CE15B39.5070207@codemonkey.ws>
References: <20101104180406.GA2820@redhat.com>
	<5f91d600c749e66de107f60298c5ebd36645beff.1288892774.git.mst@redhat.com>
	<m3oc9qr649.fsf@trasno.org> <4CE149CB.1040301@codemonkey.ws>
	<20101115151817.GA30509@redhat.com>
	<4CE15B39.5070207@codemonkey.ws>
Date: Mon, 15 Nov 2010 20:53:00 +0000
Message-ID: <AANLkTikaYDJ=NNWF0e9bp4B6GDrY20gitdvvJD632Epi@mail.gmail.com>
Subject: Re: [Qemu-devel] Re: [PATCHv2 2/2] tap: mark fd handler as device
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Juan Quintela <quintela@redhat.com>, qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>

On Mon, Nov 15, 2010 at 4:09 PM, Anthony Liguori <anthony@codemonkey.ws> wr=
ote:
> 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"<mst@redhat.com> =A0 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<mst@redhat.com>
>>>>>
>>>>
>>>> once here, what handlers make sense to run while stopped?
>>>> /me can think of the normal console, non live migration, loadvm and no=
t
>>>> much more. =A0Perhaps 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. =A0For instance, we don't rely on stop to pause pendin=
g
> disk I/O because we don't serialize pending disk I/O operations. =A0Inste=
ad,
> 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. =A0This assumption b=
reaks
> down though with ioeventfd so we need to revisit it.

vhost has a solution for this: register a VMChangeStateHandler
function that stops ioeventfd while vm_stop(0) is in effect.  Then
poll to see if there is work pending.

I will add equivalent functionality to virtio-ioeventfd.

Stefan