From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 13100A04B0; Tue, 22 Sep 2020 14:05:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AF0711DB4D; Tue, 22 Sep 2020 14:03:54 +0200 (CEST) Received: from incedge.chinasoftinc.com (unknown [114.113.233.8]) by dpdk.org (Postfix) with ESMTP id C44201DADD for ; Tue, 22 Sep 2020 14:03:43 +0200 (CEST) X-ASG-Debug-ID: 1600776221-149d111bae1ab8f0001-TfluYd Received: from mail.chinasoftinc.com (inccas002.ito.icss [10.168.0.52]) by incedge.chinasoftinc.com with ESMTP id TAa2xsDJdaEgfijv (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2020 20:03:41 +0800 (CST) X-Barracuda-Envelope-From: huwei013@chinasoftinc.com X-Barracuda-RBL-Trusted-Forwarder: 10.168.0.52 X-ASG-Whitelist: Client Received: from localhost.localdomain (120.133.139.157) by INCCAS002.ito.icss (10.168.0.60) with Microsoft SMTP Server id 14.3.487.0; Tue, 22 Sep 2020 20:03:41 +0800 From: "Wei Hu (Xavier)" X-Barracuda-RBL-Trusted-Forwarder: 10.168.0.60 To: CC: Date: Tue, 22 Sep 2020 20:03:18 +0800 X-ASG-Orig-Subj: [PATCH v2 06/17] net/hns3: avoid accessing nonexistent VF reg when PF in FLR Message-ID: <20200922120329.21185-7-huwei013@chinasoftinc.com> X-Mailer: git-send-email 2.9.5 In-Reply-To: <20200922120329.21185-1-huwei013@chinasoftinc.com> References: <20200922085401.12272-1-huwei013@chinasoftinc.com> <20200922120329.21185-1-huwei013@chinasoftinc.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [120.133.139.157] X-Barracuda-Connect: inccas002.ito.icss[10.168.0.52] X-Barracuda-Start-Time: 1600776221 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://incspam.chinasofti.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at chinasoftinc.com X-Barracuda-Scan-Msg-Size: 3044 Subject: [dpdk-dev] [PATCH v2 06/17] net/hns3: avoid accessing nonexistent VF reg when PF in FLR 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Hongbo Zheng According to the protocol of PCIe, FLR to a PF device resets the PF state as well as the SR-IOV extended capability including VF Enable which means that VFs no longer exist. When PF device is in FLR reset stage, at this time, the register state of VF device is not reliable, so VF device's register state detection is not carried out in PF FLR. In this case, we just ignore the register states to avoid accessing nonexistent register and return false in the internal function named hns3vf_is_reset_pending to indicate that there are no other reset states that need to be processed by PMD driver. Fixes: 2790c6464725 ("net/hns3: support device reset") Cc: stable@dpdk.org Signed-off-by: Hongbo Zheng Signed-off-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_ethdev.h | 7 +++++++ drivers/net/hns3/hns3_ethdev_vf.c | 15 +++++++++++++++ 2 files changed, 22 insertions(+) diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h index f170df9..3f3f973 100644 --- a/drivers/net/hns3/hns3_ethdev.h +++ b/drivers/net/hns3/hns3_ethdev.h @@ -275,6 +275,13 @@ enum hns3_reset_level { * Kernel PF driver use mailbox to inform DPDK VF to do reset, the value * of the reset level and the one defined in kernel driver should be * same. + * + * According to the protocol of PCIe, FLR to a PF resets the PF state as + * well as the SR-IOV extended capability including VF Enable which + * means that VFs no longer exist. + * + * In PF FLR, the register state of VF is not reliable, VF's driver + * should not access the registers of the VF device. */ HNS3_VF_FULL_RESET = 3, HNS3_FLR_RESET, /* A VF perform FLR reset */ diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c index 565cf60..cb2747b 100644 --- a/drivers/net/hns3/hns3_ethdev_vf.c +++ b/drivers/net/hns3/hns3_ethdev_vf.c @@ -2191,6 +2191,21 @@ hns3vf_is_reset_pending(struct hns3_adapter *hns) struct hns3_hw *hw = &hns->hw; enum hns3_reset_level reset; + /* + * According to the protocol of PCIe, FLR to a PF device resets the PF + * state as well as the SR-IOV extended capability including VF Enable + * which means that VFs no longer exist. + * + * HNS3_VF_FULL_RESET means PF device is in FLR reset. when PF device + * is in FLR stage, the register state of VF device is not reliable, + * so register states detection can not be carried out. In this case, + * we just ignore the register states and return false to indicate that + * there are no other reset states that need to be processed by driver. + */ + if (hw->reset.level == HNS3_VF_FULL_RESET) + return false; + + /* Check the registers to confirm whether there is reset pending */ hns3vf_check_event_cause(hns, NULL); reset = hns3vf_get_reset_level(hw, &hw->reset.pending); if (hw->reset.level != HNS3_NONE_RESET && hw->reset.level < reset) { -- 2.9.5