From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3A49FC02198 for ; Mon, 10 Feb 2025 05:54:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id CAA8960A62; Mon, 10 Feb 2025 05:54:16 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id 8I2kN5XW_goV; Mon, 10 Feb 2025 05:54:14 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org ACFC76064C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1739166854; bh=1J814vXtJT0jyGyTVDJee09MuSilNofXHwtUT+Nk/t4=; h=Date:From:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=xkkh5209OIrcofAgRREseZBDU3M14yRzGkdZt1kAr2Iqb/tWAvhnG/mH+hQfGrqJy EvVzYKAy+7LNkWJ7qFXE1EpRDTgK2s5eeOUlPQHbv9RNxSIt85rx3hkmbCgU6+f3u3 YHJsQ6wweVJMXunGRo8KfY+Qq2ELa7FI7zrOZt6N6lvEZy3f7OFvl/FGHR7AKwKnw6 +nv7wcu3ruVAMJtI7bGQ+Tjt9xTJ91EeUudlCIE5uA5PnsyxztI9wDM3zwZNdhEpdY Bb+WBBoIm9IpZmG2ntgdf5LjcYWPOvQzKbt7SQlPKzBeKzOBkfpwE4IO+hj2n1IXe0 OVlvrH2FnMy5w== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp3.osuosl.org (Postfix) with ESMTP id ACFC76064C; Mon, 10 Feb 2025 05:54:14 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists1.osuosl.org (Postfix) with ESMTP id 93A16199 for ; Mon, 10 Feb 2025 05:54:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 76318410BA for ; Mon, 10 Feb 2025 05:54:13 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id wqbgYWrf13Tp for ; Mon, 10 Feb 2025 05:54:12 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=198.175.65.13; helo=mgamail.intel.com; envelope-from=michal.swiatkowski@linux.intel.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp4.osuosl.org 50F0D410B6 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 50F0D410B6 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by smtp4.osuosl.org (Postfix) with ESMTPS id 50F0D410B6 for ; Mon, 10 Feb 2025 05:54:12 +0000 (UTC) X-CSE-ConnectionGUID: jFJ6VDPSRGaBQlDPabpBFw== X-CSE-MsgGUID: Ca+YR+OeTsihng2PG2A2rA== X-IronPort-AV: E=McAfee;i="6700,10204,11340"; a="50716414" X-IronPort-AV: E=Sophos;i="6.13,273,1732608000"; d="scan'208";a="50716414" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2025 21:54:11 -0800 X-CSE-ConnectionGUID: +D+F6v1gQ1+Uq2rmkOOrzw== X-CSE-MsgGUID: 3qZNfQjEQRuVMLvCv9Wc8A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,273,1732608000"; d="scan'208";a="111924120" Received: from mev-dev.igk.intel.com ([10.237.112.144]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2025 21:54:09 -0800 Date: Mon, 10 Feb 2025 06:50:37 +0100 From: Michal Swiatkowski To: Simon Horman Cc: Michal Swiatkowski , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, marcin.szycik@linux.intel.com, jedrzej.jagielski@intel.com, przemyslaw.kitszel@intel.com, piotr.kwapulinski@intel.com, anthony.l.nguyen@intel.com, dawid.osuchowski@intel.com Message-ID: References: <20250207104343.2791001-1-michal.swiatkowski@linux.intel.com> <20250207104343.2791001-4-michal.swiatkowski@linux.intel.com> <20250207145710.GX554665@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250207145710.GX554665@kernel.org> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739166852; x=1770702852; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=/u8/nOiV2tiPmC3JD800u44XyghZ/YaazPRAQSG/EZs=; b=TVDGKSrgAFKEYDpaYno41cej+gZ20t1YBLPq5WAQ7lxIRcUECbvg0fTJ g2oiUTzd2pAsaxHkg408eSFuhBf46euc/ELBVgyCmc9INs7Ct3wYSgjmW xN0tDdK6ZHfjAzgJw0ZDJqpkCbs0dNluQUM2PLm/nUWqRnx50flaY4k+I igfgsUWJrbWXSZ6z27MEVNloi0pWnW3mK4r4Sp8WRy17Hf+UCthAy+14s AQACQj0r59sf2HoKZl7WSBQof8tjZ+xnD7ZFMS0fdMaBP/EVuIdppoQeJ PT/ZthnumCI2vt1cb+mtM6ppl/HQ9oaVLc/PqSc77/UjwoWpdGSGnmLu9 g==; X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dmarc=none (p=none dis=none) header.from=linux.intel.com X-Mailman-Original-Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=TVDGKSrg Subject: Re: [Intel-wired-lan] [iwl-next v1 3/4] ixgbe: add Tx hang detection unhandled MDD X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Fri, Feb 07, 2025 at 02:57:10PM +0000, Simon Horman wrote: > On Fri, Feb 07, 2025 at 11:43:42AM +0100, Michal Swiatkowski wrote: > > From: Slawomir Mrozowicz > > > > Add Tx Hang detection due to an unhandled MDD Event. > > > > Previously, a malicious VF could disable the entire port causing > > TX to hang on the E610 card. > > Those events that caused PF to freeze were not detected > > as an MDD event and usually required a Tx Hang watchdog timer > > to catch the suspension, and perform a physical function reset. > > > > Implement flows in the affected PF driver in such a way to check > > the cause of the hang, detect it as an MDD event and log an > > entry of the malicious VF that caused the Hang. > > > > The PF blocks the malicious VF, if it continues to be the source > > of several MDD events. > > > > Reviewed-by: Przemek Kitszel > > Reviewed-by: Marcin Szycik > > Signed-off-by: Slawomir Mrozowicz > > Co-developed-by: Michal Swiatkowski > > Signed-off-by: Michal Swiatkowski > > ... > > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h > > index aa3b498558bc..e07b56625595 100644 > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h > > @@ -1044,6 +1044,7 @@ struct ixgbe_nvm_version { > > #define IXGBE_GCR_EXT_VT_MODE_16 0x00000001 > > #define IXGBE_GCR_EXT_VT_MODE_32 0x00000002 > > #define IXGBE_GCR_EXT_VT_MODE_64 0x00000003 > > +#define IXGBE_GCR_EXT_VT_MODE_MASK 0x00000003 > > nit: For consistency I think spaces should be used to indent 0x00000003 > Will fix, I wondered if I should follow normal style or be consistent. > > #define IXGBE_GCR_EXT_SRIOV (IXGBE_GCR_EXT_MSIX_EN | \ > > IXGBE_GCR_EXT_VT_MODE_64) > > > > ... > > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > > ... > > > +static u32 ixgbe_poll_tx_icache(struct ixgbe_hw *hw, u16 queue, u16 idx) > > +{ > > + IXGBE_WRITE_REG(hw, IXGBE_TXDESCIC, queue * idx); > > + return IXGBE_READ_REG(hw, IXGBE_TXDESCIC); > > +} > > + > > +/** > > + * ixgbe_check_illegal_queue - search for queue with illegal packet > > + * @adapter: structure containing ring specific data > > + * @queue: queue index > > + * > > + * Check if tx descriptor connected with input queue > > + * contains illegal packet. > > + * > > + * Returns: true if queue contain illegal packet. > > + */ > > +static bool ixgbe_check_illegal_queue(struct ixgbe_adapter *adapter, > > + u16 queue) > > +{ > > + u32 hdr_len_reg, mss_len_reg, type_reg; > > + struct ixgbe_hw *hw = &adapter->hw; > > + u32 mss_len, header_len, reg; > > + > > + for (u16 i = 0; i < IXGBE_MAX_TX_DESCRIPTORS; i++) { > > + /* HW will clear bit IXGBE_TXDESCIC_READY when address > > + * is written to address field. HW will set this bit > > + * when iCache read is done, and data is ready at TIC_DWx. > > + * Set descriptor address. > > + */ > > + read_poll_timeout(ixgbe_poll_tx_icache, reg, > > + !(reg & IXGBE_TXDESCIC_READY), 0, 0, false, > > + hw, queue, i); > > + > > + /* read tx descriptor access registers */ > > + hdr_len_reg = IXGBE_READ_REG(hw, IXGBE_TIC_DW2(IXGBE_VLAN_MACIP_LENS_REG)); > > + type_reg = IXGBE_READ_REG(hw, IXGBE_TIC_DW2(IXGBE_TYPE_TUCMD_MLHL)); > > + mss_len_reg = IXGBE_READ_REG(hw, IXGBE_TIC_DW2(IXGBE_MSS_L4LEN_IDX)); > > + > > + /* check if Advanced Context Descriptor */ > > + if (FIELD_GET(IXGBE_ADVTXD_DTYP_MASK, type_reg) != > > + IXGBE_ADVTXD_DTYP_CTXT) > > + continue; > > + > > + /* check for illegal MSS and Header length */ > > + mss_len = FIELD_GET(IXGBE_ADVTXD_MSS_MASK, mss_len_reg); > > + header_len = FIELD_GET(IXGBE_ADVTXD_HEADER_LEN_MASK, > > + hdr_len_reg); > > + if ((mss_len + header_len) > SZ_16K) { > > + e_warn(probe, > > + "mss len + header len too long\n"); > > nit: The above two lines can be a single line. > Will fix > > + return true; > > + } > > + } > > + > > + return false; > > +} > > + > > +/** > > + * ixgbe_handle_mdd_event - handle mdd event > > + * @adapter: structure containing ring specific data > > + * @tx_ring: tx descriptor ring to handle > > + * > > + * Reset VF driver if malicious vf detected or > > + * illegal packet in an any queue detected. > > + */ > > +static void ixgbe_handle_mdd_event(struct ixgbe_adapter *adapter, > > + struct ixgbe_ring *tx_ring) > > +{ > > + u16 vf, q; > > + > > + if (adapter->vfinfo && ixgbe_check_mdd_event(adapter)) { > > + /* vf mdd info and malicious vf detected */ > > + if (!ixgbe_get_vf_idx(adapter, tx_ring->queue_index, &vf)) > > + ixgbe_vf_handle_tx_hang(adapter, vf); > > + } else { > > + /* malicious vf not detected */ > > + for (q = 0; q < IXGBE_MAX_TX_QUEUES; q++) { > > + if (ixgbe_check_illegal_queue(adapter, q) && > > + !ixgbe_get_vf_idx(adapter, q, &vf)) > > + /* illegal queue detected */ > > + ixgbe_vf_handle_tx_hang(adapter, vf); > > It looks like ixgbe_vf_handle_tx_hang() will run for each illegal queue. > Could that be more than once for a given vf? If so, is that desirable? > Yes, it will be called for each hanged queue of a given VF. I assume this is fine, as the function is counting the hang events, not resetting VF. Thanks for the review, Michal > > + } > > + } > > +} > > + > > /** > > * ixgbe_clean_tx_irq - Reclaim resources after transmit completes > > * @q_vector: structure containing interrupt and ring information > > ...