net/qede/base: fix for VF malicious indication

IOV regression testing led to discovery of a minor issue + possibly race
in IOV flows:
 a. Malicious indications in VF-database on PF-side get cleared during
    FLR flows - but not when disabling SRIOV. At least in Linux if you
    disable IOV while having a malicious VF you wouldn't be able to
    clear the indication as driver would prevent from initializing it.
 b. Possible race during PF response to VF - the channel is made ready
    only after sending the rc via dmae to VF. It's possible due to
    context switch at end of DMAE [when releasing Mutex] that VF would
    start running and send another message prior to PF clearing the
    channel, making the FW consider that VF to be malicious.

This patch fixes that by
 - clearing the indication even if we're only going to disable VF
 - resetting the channel to ready before PF copies the rc to the VF, PF
   can then continue and send an additional message

Fixes: 47b302d64624 ("net/qede/base: add handling of malicious VF")
Fixes: 86a2265e59d7 ("qede: add SRIOV support")
Cc: stable@dpdk.org
Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com>

diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c
index b85718f..18458cf 100644 (file)
--- a/drivers/net/qede/base/ecore_sriov.c
+++ b/drivers/net/qede/base/ecore_sriov.c
@@ -865,6 +865,11 @@ ecore_iov_enable_vf_access(struct ecore_hwfn *p_hwfn,
        u32 igu_vf_conf = IGU_VF_CONF_FUNC_EN;
        enum _ecore_status_t rc = ECORE_SUCCESS;
 
+       /* It's possible VF was previously considered malicious -
+        * clear the indication even if we're only going to disable VF.
+        */
+       vf->b_malicious = false;
+
        if (vf->to_disable)
                return ECORE_SUCCESS;
 
@@ -877,8 +882,6 @@ ecore_iov_enable_vf_access(struct ecore_hwfn *p_hwfn,
 
        ecore_iov_vf_igu_reset(p_hwfn, p_ptt, vf);
 
-       /* It's possible VF was previously considered malicious */
-       vf->b_malicious = false;
        rc = ecore_iov_enable_vf_access_msix(p_hwfn, p_ptt,
                                             vf->abs_vf_id, vf->num_sbs);
        if (rc != ECORE_SUCCESS)
@@ -1397,14 +1400,18 @@ static void ecore_iov_send_response(struct ecore_hwfn *p_hwfn,
                             (sizeof(union pfvf_tlvs) - sizeof(u64)) / 4,
                             &params);
 
-       ecore_dmae_host2host(p_hwfn, p_ptt, mbx->reply_phys,
-                            mbx->req_virt->first_tlv.reply_address,
-                            sizeof(u64) / 4, &params);
-
+       /* Once PF copies the rc to the VF, the latter can continue and
+        * and send an additional message. So we have to make sure the
+        * channel would be re-set to ready prior to that.
+        */
        REG_WR(p_hwfn,
               GTT_BAR0_MAP_REG_USDM_RAM +
               USTORM_VF_PF_CHANNEL_READY_OFFSET(eng_vf_id), 1);
 
+       ecore_dmae_host2host(p_hwfn, p_ptt, mbx->reply_phys,
+                            mbx->req_virt->first_tlv.reply_address,
+                            sizeof(u64) / 4, &params);
+
        OSAL_IOV_PF_RESP_TYPE(p_hwfn, p_vf->relative_vf_id, status);
 }