From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id AAFA26CC0 for ; Mon, 9 May 2016 18:25:43 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 09 May 2016 09:25:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,601,1455004800"; d="scan'208";a="971893645" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 09 May 2016 09:25:42 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 9 May 2016 09:25:41 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 9 May 2016 09:25:41 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.148]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002; Tue, 10 May 2016 00:25:39 +0800 From: "Xie, Huawei" To: Yuanhan Liu , "dev@dpdk.org" CC: "Michael S. Tsirkin" Thread-Topic: [PATCH 4/6] vhost: workaround stale vring base Thread-Index: AdGqD2vpS/uehSl3TSCesgK09fe49Q== Date: Mon, 9 May 2016 16:25:38 +0000 Message-ID: References: <1462603224-29510-1-git-send-email-yuanhan.liu@linux.intel.com> <1462603224-29510-5-git-send-email-yuanhan.liu@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 09 May 2016 16:25:44 -0000 On 5/7/2016 2:36 PM, Yuanhan Liu wrote:=0A= > However, Michael claims some concerns: he made a good point: a crash=0A= > is happening means some memory is corrupted, and it could be the virtio= =0A= > memory being corrupted. In such case, nothing will work without the=0A= > reset.=0A= =0A= I don't get this point. What is the scenario?=0A= For the crash of virtio frontend driver, i remember we discussed before,=0A= we have no good recipe but some workaround. The user space frontend=0A= driver crashes, and its memory is reallocated to other instances, but=0A= vhost is still writing to that memory. However this has nothing to do=0A= with vhost reconnect.=0A=