From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 1FAA85A44 for ; Thu, 13 Sep 2018 15:39:36 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 06:39:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,369,1531810800"; d="scan'208";a="89703815" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.207]) by fmsmga001.fm.intel.com with ESMTP; 13 Sep 2018 06:37:37 -0700 Date: Fri, 14 Sep 2018 04:25:28 +0800 From: Ye Xiaolong To: "Wang, Xiao W" Cc: "Bie, Tiwei" , "dev@dpdk.org" Message-ID: <20180913202528.GA20985@intel.com> References: <20180910110531.138449-1-xiao.w.wang@intel.com> <20180913125519.GA13400@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH] net/ifc: do not notify before HW ready X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 13:39:37 -0000 On 09/13, Wang, Xiao W wrote: >Hi Xiaolong, > >> -----Original Message----- >> From: Ye, Xiaolong >> Sent: Thursday, September 13, 2018 8:55 PM >> To: Wang, Xiao W >> Cc: Bie, Tiwei ; dev@dpdk.org >> Subject: Re: [PATCH] net/ifc: do not notify before HW ready >> >> Hi, Xiao >> >> On 09/10, Xiao Wang wrote: >> >Fixes: a3f8150eac6d ("net/ifcvf: add ifcvf vDPA driver") >> >> Could you help describe what problem is without this fix in commit log? > >Generally a driver should finish all the device configurations first then notify the HW for data processing. >Without this fix, the potential problems are: >1. If the device is not clearly reset by the previous driver and holds some invalid ring addr, and the vDPA relay thread kicks it, a bad DMA request may happen. >2. The notify_addr which is used by the relay thread is set in the vdpa_ifcvf_start function. If there's really a kick relay before vdpa_ifcvf_start finishes, a null addr is accessed. > Thanks for the explanation. Thanks, Xiaolong >Would add the description in the commit log in v2. > >Thanks for the comment, >Xiao >> >> Thanks, >> Xiaolong >> > >> >Signed-off-by: Xiao Wang >> >--- >> > drivers/net/ifc/ifcvf_vdpa.c | 8 ++++---- >> > 1 file changed, 4 insertions(+), 4 deletions(-) >> > >> >diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c >> >index 3c5430dc0..7d3085d8d 100644 >> >--- a/drivers/net/ifc/ifcvf_vdpa.c >> >+++ b/drivers/net/ifc/ifcvf_vdpa.c >> >@@ -503,11 +503,11 @@ update_datapath(struct ifcvf_internal *internal) >> > if (ret) >> > goto err; >> > >> >- ret = setup_notify_relay(internal); >> >+ ret = vdpa_ifcvf_start(internal); >> > if (ret) >> > goto err; >> > >> >- ret = vdpa_ifcvf_start(internal); >> >+ ret = setup_notify_relay(internal); >> > if (ret) >> > goto err; >> > >> >@@ -515,12 +515,12 @@ update_datapath(struct ifcvf_internal *internal) >> > } else if (rte_atomic32_read(&internal->running) && >> > (!rte_atomic32_read(&internal->started) || >> > !rte_atomic32_read(&internal->dev_attached))) { >> >- vdpa_ifcvf_stop(internal); >> >- >> > ret = unset_notify_relay(internal); >> > if (ret) >> > goto err; >> > >> >+ vdpa_ifcvf_stop(internal); >> >+ >> > ret = vdpa_disable_vfio_intr(internal); >> > if (ret) >> > goto err; >> >-- >> >2.15.1 >> >