From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id C11B31B249 for ; Mon, 30 Oct 2017 16:38:03 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id b189so16646786wmd.4 for ; Mon, 30 Oct 2017 08:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=qfdqcg3zAJfZBYgj2rmEW3ZpKkB4GGexGCqtk8ZFamg=; b=bb4lJ9Uql4QU84uH28qOk5lELvrm+0NBUZDS2DjJhAY/cU7HCca8zfxPwLG9OvoIC+ p2/UVe4Iph9ve8QmBtG9cX742+0pynih/k6hdXdU35gMGEHZsjNYxjw/JyCB3Ihmbig/ uxpUSik3irYFrc6eqhfw/kQBfFzuryEBriCnCZf555VW4NyiCdmehqr5EYmnepWxv6yj HwldPek5zkoN9RZM8AcdlKin/z2I2f5e7UAkpL+ifxdkQ5qokPfjmo3RwL+C/XjFbElB AHHAPKSZmiDwSj1Ej3ehadGT9ZM401yvRpQEMoQk0/p6IXdkW/hkqxoh9OXmhjdYlsvO xHFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=qfdqcg3zAJfZBYgj2rmEW3ZpKkB4GGexGCqtk8ZFamg=; b=DUVf1FCLvNw45ZkPI5yZK0lL3rJD/IhuN0KsuW7nHrnNJQwaoJ7ESOWGOHURwFmYb3 wHq9lW2J9DiByZ80MaBH67krnfp3YT0NWmGOqFjptdiwdeTWnjIimztis4TUhi/ZOofR 9MFiPPIskYpuNtkb9DXDrlxZID8zZ2O+hK/fA6pxFRCE6Q6B6auQ+YevaVbR9/0xP1DJ UxqhNy2w2UsgIDAFH9JvRy+RT0G/LZ7CmWZCBsI/V+Oo+XJFQZo/c3a9VuKbScTt/HJP AfEbUwSYLWi14wtSg1sMM9msDUthSpic2zkzMm2g0zqNtMGZENhFsr2SuQrRd8OJZdnL kd7g== X-Gm-Message-State: AMCzsaVHtx+hwyec0LSPJvB0G3Ba+ilU/vQRUusobYI6Bszw1ZJz6J6j DNH/q3fE6paxfrAFjkGmIjedgHnmfy0= X-Google-Smtp-Source: ABhQp+QtpPoIzgrRHt2ZT7BtUs7geeEuOHc/rEpZNUzLFsZMEYBhky2CLnaeYnSZ3PDNXxFDLxS54w== X-Received: by 10.28.112.22 with SMTP id l22mr3967161wmc.35.1509377883492; Mon, 30 Oct 2017 08:38:03 -0700 (PDT) Received: from localhost ([2a00:23c5:bef3:400:4a51:b7ff:fe0b:4749]) by smtp.gmail.com with ESMTPSA id r2sm3538672wmb.38.2017.10.30.08.38.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Oct 2017 08:38:02 -0700 (PDT) From: luca.boccassi@gmail.com To: Rasesh Mody Cc: dpdk stable Date: Mon, 30 Oct 2017 15:34:51 +0000 Message-Id: <20171030153511.13322-48-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20171030153511.13322-1-luca.boccassi@gmail.com> References: <20171030153511.13322-1-luca.boccassi@gmail.com> Subject: [dpdk-stable] patch 'net/qede/base: fix for VF malicious indication' has been queued to LTS release 16.11.4 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 15:38:03 -0000 Hi, FYI, your patch has been queued to LTS release 16.11.4 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 11/01/17. So please shout if anyone has objections. Thanks. Kind regards, Luca Boccassi --- >>From 8bb1056d29df9a6e1a85149da3924e9c8f024b4a Mon Sep 17 00:00:00 2001 From: Rasesh Mody Date: Fri, 6 Oct 2017 23:31:10 -0700 Subject: [PATCH] net/qede/base: fix for VF malicious indication [ upstream commit eb35c732fe7c82dbf4b1115030e75a7d212350b8 ] 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") Signed-off-by: Rasesh Mody --- drivers/net/qede/base/ecore_sriov.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/net/qede/base/ecore_sriov.c b/drivers/net/qede/base/ecore_sriov.c index b28d72810..1e706654b 100644 --- a/drivers/net/qede/base/ecore_sriov.c +++ b/drivers/net/qede/base/ecore_sriov.c @@ -1214,13 +1214,17 @@ static void ecore_iov_send_response(struct ecore_hwfn *p_hwfn, (sizeof(union pfvf_tlvs) - sizeof(u64)) / 4, ¶ms); - ecore_dmae_host2host(p_hwfn, p_ptt, mbx->reply_phys, - mbx->req_virt->first_tlv.reply_address, - sizeof(u64) / 4, ¶ms); - + /* 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, ¶ms); } static u16 ecore_iov_vport_to_tlv(struct ecore_hwfn *p_hwfn, -- 2.11.0