From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35562 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POR9z-0003g2-C0 for qemu-devel@nongnu.org; Fri, 03 Dec 2010 03:38:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POR9x-0002Pz-MY for qemu-devel@nongnu.org; Fri, 03 Dec 2010 03:38:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POR9x-0002Pq-Ed for qemu-devel@nongnu.org; Fri, 03 Dec 2010 03:38:29 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB38cSbi023930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Dec 2010 03:38:28 -0500 Message-ID: <4CF8ACC2.4020200@redhat.com> Date: Fri, 03 Dec 2010 09:39:30 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCHv3 4/6] virtio-net: stop/start bh when appropriate References: <20101129153718.GA2494@redhat.com> <19701.57573.766694.450729@gargle.gargle.HOWL> <20101201060252.GB9199@redhat.com> <19703.38782.929586.869640@gargle.gargle.HOWL> <20101202130823.GD2454@redhat.com> <19703.43787.213477.834653@gargle.gargle.HOWL> <20101202182722.GA7211@redhat.com> In-Reply-To: <20101202182722.GA7211@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Jason Wang , mtosatti@redhat.com, qemu-devel@nongnu.org, quintela@redhat.com Am 02.12.2010 19:27, schrieb Michael S. Tsirkin: > On Thu, Dec 02, 2010 at 10:19:55PM +0800, Jason Wang wrote: >> Michael S. Tsirkin writes: >> > On Thu, Dec 02, 2010 at 08:56:30PM +0800, Jason Wang wrote: >> > > Michael S. Tsirkin writes: >> > > > On Wed, Dec 01, 2010 at 01:45:09PM +0800, Jason Wang wrote: >> > > > > Michael S. Tsirkin writes: >> > > > > > Avoid sending out packets, and modifying >> > > > > > device state, when VM is stopped. >> > > > > > Add assert statements to verify this does not happen. >> > > > > > >> > > > > > Avoid scheduling bh when vhost-net is started. >> > > > > > >> > > > > > Stop bh when driver disabled bus mastering >> > > > > > (we must not access memory after this). >> > > > > > >> > > > > > Signed-off-by: Michael S. Tsirkin >> > > > > > >> > > > > >> > > > > There's no need to disable it bh we call qemu_aio_flush() after >> > > > > vm_state_notify() in do_vm_stop(). And for timer, looks like every device should >> > > > > stop its timer in vm state change handler, not only for virtio-net? >> > > > >> > > > BTW I fixed some typos. Here a fixed version. >> > > > Jason, could you review/test please? >> > > > >> > > >> > > Have done the test, it's more stable than before but still get small deltas in >> > > cpu section. >> > >> > And just to clarify: no more deltas in the memory section? >> > >> >> Yes. >> >> And the offset for cpu section is 1161-1165 and sometimes I get deltas for ide >> section at offset 295 and 314. > > > Kevin, could you take a look please? > > Jason, does the following do anything? > > Subject: ide: cancel bh on vm stop > > If bh is running on vm stop, ide state might change > after vm stop is completed. Solve by deleting bh on stop. > > Signed-off-by: Michael S. Tsirkin > > diff --git a/hw/ide/core.c b/hw/ide/core.c > index 484e0ca..8d86114 100644 > --- a/hw/ide/core.c > +++ b/hw/ide/core.c > @@ -698,8 +698,13 @@ void ide_dma_restart_cb(void *opaque, int running, int reason) > { > BMDMAState *bm = opaque; > > - if (!running) > + if (!running) { > + if (bm->bh) { > + qemu_bh_delete(bm->bh); > + bm->bh = NULL; > + } > return; > + } > > if (!bm->bh) { > bm->bh = qemu_bh_new(ide_dma_restart_bh, bm); Doesn't look incorrect to me, though I would be surprised if you ever hit the case where bm->bh is not NULL. It would mean that immediately after a cont the VM is stopped again. This bottom half is only ever used in the vm_change_handler. Considering that above was mentioned that a qemu_aio_flush() is run, I also don't think that it makes any difference. Kevin