From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id B303B5955 for ; Mon, 13 Jun 2016 22:47:36 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F4F23B72F; Mon, 13 Jun 2016 20:47:36 +0000 (UTC) Received: from redhat.com (vpn1-6-220.ams2.redhat.com [10.36.6.220]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id u5DKlXa4023889; Mon, 13 Jun 2016 16:47:34 -0400 Date: Mon, 13 Jun 2016 23:47:33 +0300 From: "Michael S. Tsirkin" To: Yuanhan Liu Cc: "Xie, Huawei" , "dev@dpdk.org" , mlureau@redhat.com Message-ID: <20160613234551-mutt-send-email-mst@redhat.com> References: <1462603224-29510-1-git-send-email-yuanhan.liu@linux.intel.com> <1462603224-29510-5-git-send-email-yuanhan.liu@linux.intel.com> <20160509182204.GF5641@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160509182204.GF5641@yliu-dev.sh.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 13 Jun 2016 20:47:36 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 4/6] vhost: workaround stale vring base X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 20:47:36 -0000 On Mon, May 09, 2016 at 11:22:04AM -0700, Yuanhan Liu wrote: > On Mon, May 09, 2016 at 04:25:38PM +0000, Xie, Huawei wrote: > > On 5/7/2016 2:36 PM, Yuanhan Liu wrote: > > > However, Michael claims some concerns: he made a good point: a crash > > > is happening means some memory is corrupted, and it could be the virtio > > > memory being corrupted. In such case, nothing will work without the > > > reset. > > > > I don't get this point. What is the scenario? > > It's not a specific scenario, just a hypothetic one. > > > For the crash of virtio frontend driver, i remember we discussed before, > > we have no good recipe but some workaround. The user space frontend > > driver crashes, and its memory is reallocated to other instances, but > > vhost is still writing to that memory. However this has nothing to do > > with vhost reconnect. > > Hmm, yes, seems like another good point to me. This patch seems like > a fix but not a workaround then :) > > --yliu I think it's a good idea to make sure the ring is already setup by this time though. Some future QEMU version might send base idx before it will setup the ring, we would not want to crash. Hopefully it will have fixed the base value sent by then. -- MST