Received: by 2002:ab2:69cc:0:b0:1f4:be93:e15a with SMTP id n12csp1811921lqp; Mon, 15 Apr 2024 19:58:36 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXe1/oUAjybIr5IDyvBaF4Hmfy+pytc5M6HmjKjYIkf6FpHKIJo/PuZX1EPAvIraZtwoJ92IgyyjHyFA3E67987w3XwJeq85iZJ/c03AA== X-Google-Smtp-Source: AGHT+IEvkr1SfGgldYQVm759ikTtlvSeweZouHRICQKHpIFAnJIm/vcqqVgXxvfOucUO7PvykL/r X-Received: by 2002:ae9:e312:0:b0:78d:5c65:f2a0 with SMTP id v18-20020ae9e312000000b0078d5c65f2a0mr13316888qkf.21.1713236316422; Mon, 15 Apr 2024 19:58:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713236316; cv=pass; d=google.com; s=arc-20160816; b=GWrLUIQPBmr6lVrECjxauCEiGUtVBS6gcVAf/9rVjIz7IOGB8PaXEZGikpdVeYiDAW xbmICNgJaTLjwIV+RW+y4z0EPldTFQ09h6uWtd8+jqXks2g+bUI1P2wrZyi0/DddeMbM U5WQoGa2RNK6FriHvvZ7KjnpWp0oJSpA/aU5Nl9c28p9wSgreWFigZHHn3Vvlj2Fqart xjI4feO0q47KVN8iseIVklU80k6HmradR/6/OlksMK6w7x+DMJwrVMkq7NWiphnzlC4N S7GHeFuhFePeUJObVGjJeW8peunhk2x9eUUytD4YtroCGa14hbPexobvolBr4jEl42o6 bdFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:cc:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=T61IkRblSDpUQ9zOey0zucQ7xiOkDgFXsYEI80rW3vQ=; fh=ueRItA/L4PVmFd+SBJES0/a+wYlPifFKTvfvSBbySQ0=; b=YAhJWaeGLK8FJeSwfsoa0qc9LNsqItZofagBZkE+vLmjeci2Z81FaAlHwL7TyTAszp GNYDo+teT4n5JtYPYihGd4AOtsIbvHs74AnYSLNsKRDa6eTMWQ7EMK6f4PfwHzO/ayAy 9Z3SISjSkBkJs4x16zSz3nyi+GIA/xZJsP0l4WXVcKBb/wvCzpb8UDxvpeMAO6W/tQiR jqYngoLdK0Wu4FOQJ8p2p/ODco9C/JkZlU5w+JHIUznWATDdQ37ulAcd6nqbhFnHpX+x AYX+YqRGnoI86dFppaQxLbPuLyxd9kozasOmKwAEH0ZA6kGiiMbjbxRX1ja9YuaIoDqX nOpA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ckdnkwWG; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-146138-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-146138-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id dv11-20020a05620a1b8b00b0078ed71440dcsi7597037qkb.608.2024.04.15.19.58.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Apr 2024 19:58:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-146138-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ckdnkwWG; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-146138-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-146138-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 28A9D1C20B7E for ; Tue, 16 Apr 2024 02:58:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AD3D5134BC; Tue, 16 Apr 2024 02:58:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ckdnkwWG" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F05E6199BC for ; Tue, 16 Apr 2024 02:58:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713236307; cv=none; b=pJfhmLm+7bbwlI9PYawIHwm5FsUAdV8XC0VnmnUL22ZNqzFOPGsXlYTtBoQm6ewW0tv5XOCvfHMbXrFaqNzxhQYEOjhLM4rUoYw3EDd2F+f6FlqjLsuQBQHA28ZEKVdexavlejLXAlCa9qAP/Lq0VViYeGCEAAq/R0Ji77cxxXw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713236307; c=relaxed/simple; bh=BnwpGwNp+5YU6aApL0zOgln6MzekW8/Pu06ULLBFAkQ=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=fok4ENPxA7dLLfpvT3bimWGtaR+Q8tx9bI9LhoyUdpMYvDKeZSgqoi64E5/eDfbgJ660TxlRZ5E//7BQtj3yGGHslc4sYmTe27dxNMF2BvojzhNbNRMe0OjwoUII1AZmNvLn+9hHxIgmpeivI2g7zTfb3UEFOKwRWbfggIB9K4g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ckdnkwWG; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713236305; x=1744772305; h=message-id:date:mime-version:cc:subject:to:references: from:in-reply-to:content-transfer-encoding; bh=BnwpGwNp+5YU6aApL0zOgln6MzekW8/Pu06ULLBFAkQ=; b=ckdnkwWGxSJax2RGwxXKgj5RJSer56qqoujEYwQsAYYUrhLPrhPWt3vG uwQujXNvYOULvGIcvnbrGS3U8RhuzPHxCMj9sCnUSD25Lq7xKxx5fEoK9 AQr3ez2u9+ysScFPBxwdMyNEMKeGZI3iXWnmI36QvKFOiM+JT2VTqm4US iiiSU+3G/tixGT6QyyhzKaLn6vOHnLWB57CIo1x7AJI3z0XkQYCihL0b0 RzaBHA2aQFu2kCes5jYJ+qEWHsglW50Tog6WCL/tfh3oPZSmNMdgOOwhh jS+QBq/CW5BUszoNvNFt778b4jaRUqRYhJOrE4AJi1GJzKRwRXhkvx+SK A==; X-CSE-ConnectionGUID: wx6J60URTwC4yEqSO0euTQ== X-CSE-MsgGUID: aMLkkFD6QGiewYU8x9fC/w== X-IronPort-AV: E=McAfee;i="6600,9927,11045"; a="19256858" X-IronPort-AV: E=Sophos;i="6.07,204,1708416000"; d="scan'208";a="19256858" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 19:58:24 -0700 X-CSE-ConnectionGUID: Sa8bw42ATN+0hXTMrkACLA== X-CSE-MsgGUID: DEVMaxGMSre/3Yd0zWhUZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,204,1708416000"; d="scan'208";a="26767880" Received: from unknown (HELO [10.239.159.127]) ([10.239.159.127]) by fmviesa004.fm.intel.com with ESMTP; 15 Apr 2024 19:58:21 -0700 Message-ID: Date: Tue, 16 Apr 2024 10:57:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: baolu.lu@linux.intel.com, Kevin Tian , Yi Liu , Jacob Pan , Joerg Roedel , Will Deacon , Robin Murphy , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/1] iommu/vt-d: Remove caching mode check before device TLB flush To: Ethan Zhao , iommu@lists.linux.dev References: <20240415013835.9527-1-baolu.lu@linux.intel.com> <9ba0b6a2-e6c1-46de-8d30-929567952c54@linux.intel.com> Content-Language: en-US From: Baolu Lu In-Reply-To: <9ba0b6a2-e6c1-46de-8d30-929567952c54@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/16/24 8:53 AM, Ethan Zhao wrote: > On 4/15/2024 9:38 AM, Lu Baolu wrote: >> The Caching Mode (CM) of the Intel IOMMU indicates if the hardware >> implementation caches not-present or erroneous translation-structure >> entries except for the first-stage translation. The caching mode is >> irrelevant to the device TLB, therefore there is no need to check it >> before a device TLB invalidation operation. >> >> Remove two caching mode checks before device TLB invalidation in the >> driver. The removal of these checks doesn't change the driver's behavior >> in critical map/unmap paths. Hence, there is no functionality or >> performance impact, especially since commit <29b32839725f> ("iommu/vt-d: >> Do not use flush-queue when caching-mode is on") has already disabled >> flush-queue for caching mode. Therefore, caching mode will never call >> intel_flush_iotlb_all(). >> >> Signed-off-by: Lu Baolu >> Reviewed-by: Kevin Tian >> --- >>   drivers/iommu/intel/iommu.c | 9 ++------- >>   1 file changed, 2 insertions(+), 7 deletions(-) >> >> Change log: >> v3: >>   - It turned out that the removals don't change the driver's behavior, >>     hence change it from a fix patch to a cleanup one. >>   - No functionality changes. >> v2: >> https://lore.kernel.org/lkml/20240410055823.264501-1-baolu.lu@linux.intel.com/ >>   - Squash two patches into a single one. >>   - No functionality changes. >> v1: >> https://lore.kernel.org/linux-iommu/20240407144232.190355-1-baolu.lu@linux.intel.com/ >> >> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c >> index a7ecd90303dc..f0a67e9d9faf 100644 >> --- a/drivers/iommu/intel/iommu.c >> +++ b/drivers/iommu/intel/iommu.c >> @@ -1501,11 +1501,7 @@ static void iommu_flush_iotlb_psi(struct >> intel_iommu *iommu, >>       else >>           __iommu_flush_iotlb_psi(iommu, did, pfn, pages, ih); >> -    /* >> -     * In caching mode, changes of pages from non-present to present >> require >> -     * flush. However, device IOTLB doesn't need to be flushed in >> this case. >> -     */ >> -    if (!cap_caching_mode(iommu->cap) || !map) >> +    if (!map) >>           iommu_flush_dev_iotlb(domain, addr, mask); >>   } > > Given devTLB flushing is irrelavent to CM, put iommu_flush_dev_iotlb() > in iommu_flush_iotlb_psi() and called with CM checking context is not > reasonable. the logic is buggy. > > static void __mapping_notify_one(struct intel_iommu *iommu, struct > dmar_domain *domain, >                  unsigned long pfn, unsigned int pages) > { >     /* >      * It's a non-present to present mapping. Only flush if caching mode >      * and second level. >      */ >     if (cap_caching_mode(iommu->cap) && !domain->use_first_level) >         iommu_flush_iotlb_psi(iommu, domain, pfn, pages, 0, 1); >     else >         iommu_flush_write_buffer(iommu); > > > then how about fold all CM checking logic in iommu_flush_iotlb_psi() > or speperate iommu_flush_dev_iotlb() from iommu_flush_iotlb_psi() ? I am refactoring the code with a new series. https://lore.kernel.org/linux-iommu/20240410020844.253535-1-baolu.lu@linux.intel.com/ Best regards, baolu