Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp926463pxj; Wed, 16 Jun 2021 17:26:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/jWprv3T4SVnqfPTJCvGMOhJnTp7pG3xlpWP7u8GeJQULyNz+EToo7Q55DEYfOwhDty9z X-Received: by 2002:a05:6402:151:: with SMTP id s17mr2829952edu.233.1623889619137; Wed, 16 Jun 2021 17:26:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623889619; cv=none; d=google.com; s=arc-20160816; b=h8bOZrGrfx2JkKt56XVJG3SmKgMC5lnzMBX4cJiTPBK3Ml7pXYfZGNdtc/dcqzItsz 9C5ZmaDVw/aQleONFNAYFBvUn8IEf5TbE/L86C6FqJBW6obBtcsnbD4f2q8VY0/BvOQ/ ZABeM8cliIPnI7sdPOSQYoz+Wt6tnw3+blobZmZ4k2ca0wmLRzubfYnKi3BIxQF/amkg jAj5/UniOmzRpyu37uOdZipaLzB6EHQ0w0sYSShsyXDWbOG5MbQ6iR3TX0KKLc2lYmw7 22dIOJRjJ/puM/4vYSaYEINZrewJqTv+02y29WRm1Ngj/F1bHJNDP49YzALxy3wiYHUQ fZcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=TtYQyL17NXLLpd8+5ExNmMBmbaQCRFOGIzgQ/aCfSeo=; b=zMPAU5xbdsnacy5fpDQsx/kZ38Q+1tq2HFz8MM4D0ou4SMrkjLsMGGSgxELcP6vUw/ Yv1KsWXrVYAXhYWoKATJIleBCtr0EFIyOt9n9X4mnTijVzKx6raSFziL6mD4UKN9wWBb CW7+W0Z3eEP59RoGNHxWPPjofUqFMxXf8Yya2XaNPxczLwLczCXoY1+aUtZNpnhUJfaw rlSg1DdBxdj2dpQ5k1JhsM90PATPNj/UDzBHn+5Z5EtgN4FvlGBQDL+DS19uOXGLdtE7 xPDygW4cXpPL3FbJ8JQTc5GKmCCVUZnykV5beuq9tHxZqNsIvBYwTqX96/I9N4csOtMy lwcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=osZrJ4WY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l8si3694442ejc.229.2021.06.16.17.26.36; Wed, 16 Jun 2021 17:26:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=osZrJ4WY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231500AbhFPRgq (ORCPT + 99 others); Wed, 16 Jun 2021 13:36:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231459AbhFPRgl (ORCPT ); Wed, 16 Jun 2021 13:36:41 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55155C0617AD for ; Wed, 16 Jun 2021 10:34:33 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id g6so2796186pfq.1 for ; Wed, 16 Jun 2021 10:34:33 -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 :mime-version:content-transfer-encoding; bh=TtYQyL17NXLLpd8+5ExNmMBmbaQCRFOGIzgQ/aCfSeo=; b=osZrJ4WYIlJ61BclVIFe2+s1W/jbU27ZXJFZHNkTruocrdtfL0YG5EPsmrHn1dvAXd MO3P1d+RVZiAjnuyetS34JsTPQyo71cXezXHjaWOWAoQFBvnZ61gtEsSOL+OTpRUAydr 5xCGn+FzuT6gyBu5UR5p8d3O1bKWMolqa2R9ed+HHdPpZ5NncAZRAJsucO6Bd29R+8Si GtYNUuZvLayo6bCAPMGMyOsK8L2FgFQlZIiQrQIO34dKRja1FgCBAhEqSH/2VgnauDB/ nf/nqqZO4/cnoB2dJdnN0wjGRhvOqVKh+HRr1pQUNHbgSVfnGm0HaiRpzX3IY8H7f4+h 68kg== 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:mime-version:content-transfer-encoding; bh=TtYQyL17NXLLpd8+5ExNmMBmbaQCRFOGIzgQ/aCfSeo=; b=qbyi+I1yaZJc1/63iWcGyXUxYrP0jJ9DsQhQ495wAOh3kjfyW5fpeeSurk7BU01re3 fWkAN1M5StjFRzDE3bAtC+tqE1VB+y/zPHONCj0RB0wXM9VZaTwURL2pNQpiOOsWxUws frg5rNwf5D0uyR1NlMpUKoSsSYoWHl874k2W/BJtsdgxV+FdTxw0DzygB3mEo8IJkmc/ fvBRIS99AIgjhyGSKE+ZzHkt3TYKgoS9WzOPNZyJc9RooDFBVYqbJumGqM51E0Ctxvdo ROkdlvlnm6+rfZtdI+AW9tJdWbId9+zTL2CMZwqWvLMZGDLBLnpT2JsEpRO+hsm3qN10 q/IA== X-Gm-Message-State: AOAM533cF+nxez3xw23WnLpN/D9UN4+lxt4xCtfaRP4iM19PyVrXGQD3 CtYBZvx2YwSiTUmTXXvxN+g= X-Received: by 2002:a62:aa01:0:b029:2ea:743:6693 with SMTP id e1-20020a62aa010000b02902ea07436693mr902083pff.68.1623864873264; Wed, 16 Jun 2021 10:34:33 -0700 (PDT) Received: from sc2-haas01-esx0118.eng.vmware.com ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id m3sm2933901pfh.174.2021.06.16.10.34.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 10:34:32 -0700 (PDT) From: Nadav Amit X-Google-Original-From: Nadav Amit To: Joerg Roedel Cc: Nadav Amit , Will Deacon , Jiajun Cao , Lu Baolu , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Robin Murphy Subject: [PATCH v4 7/7] iommu/amd: Use only natural aligned flushes in a VM Date: Wed, 16 Jun 2021 03:05:00 -0700 Message-Id: <20210616100500.174507-8-namit@vmware.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210616100500.174507-1-namit@vmware.com> References: <20210616100500.174507-1-namit@vmware.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nadav Amit When running on an AMD vIOMMU, it is better to avoid TLB flushes of unmodified PTEs. vIOMMUs require the hypervisor to synchronize the virtualized IOMMU's PTEs with the physical ones. This process induce overheads. AMD IOMMU allows us to flush any range that is aligned to the power of 2. So when running on top of a vIOMMU, break the range into sub-ranges that are naturally aligned, and flush each one separately. This apporach is better when running with a vIOMMU, but on physical IOMMUs, the penalty of IOTLB misses due to unnecessary flushed entries is likely to be low. Repurpose (i.e., keeping the name, changing the logic) domain_flush_pages() so it is used to choose whether to perform one flush of the whole range or multiple ones to avoid flushing unnecessary ranges. Use NpCache, as usual, to infer whether the IOMMU is physical or virtual. Cc: Joerg Roedel Cc: Will Deacon Cc: Jiajun Cao Cc: Lu Baolu Cc: iommu@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Suggested-by: Robin Murphy Signed-off-by: Nadav Amit --- drivers/iommu/amd/iommu.c | 47 ++++++++++++++++++++++++++++++++++----- 1 file changed, 42 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index ce8e970aac9a..ec0b6ad27e48 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -1262,15 +1262,52 @@ static void __domain_flush_pages(struct protection_domain *domain, } static void domain_flush_pages(struct protection_domain *domain, - u64 address, size_t size) + u64 address, size_t size, int pde) { - __domain_flush_pages(domain, address, size, 0); + if (likely(!amd_iommu_np_cache)) { + __domain_flush_pages(domain, address, size, pde); + return; + } + + /* + * When NpCache is on, we infer that we run in a VM and use a vIOMMU. + * In such setups it is best to avoid flushes of ranges which are not + * naturally aligned, since it would lead to flushes of unmodified + * PTEs. Such flushes would require the hypervisor to do more work than + * necessary. Therefore, perform repeated flushes of aligned ranges + * until you cover the range. Each iteration flush the smaller between + * the natural alignment of the address that we flush and the highest + * bit that is set in the remaining size. + */ + while (size != 0) { + int addr_alignment = __ffs(address); + int size_alignment = __fls(size); + int min_alignment; + size_t flush_size; + + /* + * size is always non-zero, but address might be zero, causing + * addr_alignment to be negative. As the casting of the + * argument in __ffs(address) to long might trim the high bits + * of the address on x86-32, cast to long when doing the check. + */ + if (likely((unsigned long)address != 0)) + min_alignment = min(addr_alignment, size_alignment); + else + min_alignment = size_alignment; + + flush_size = 1ul << min_alignment; + + __domain_flush_pages(domain, address, flush_size, pde); + address += flush_size; + size -= flush_size; + } } /* Flush the whole IO/TLB for a given protection domain - including PDE */ void amd_iommu_domain_flush_tlb_pde(struct protection_domain *domain) { - __domain_flush_pages(domain, 0, CMD_INV_IOMMU_ALL_PAGES_ADDRESS, 1); + domain_flush_pages(domain, 0, CMD_INV_IOMMU_ALL_PAGES_ADDRESS, 1); } void amd_iommu_domain_flush_complete(struct protection_domain *domain) @@ -1297,7 +1334,7 @@ static void domain_flush_np_cache(struct protection_domain *domain, unsigned long flags; spin_lock_irqsave(&domain->lock, flags); - domain_flush_pages(domain, iova, size); + domain_flush_pages(domain, iova, size, 1); amd_iommu_domain_flush_complete(domain); spin_unlock_irqrestore(&domain->lock, flags); } @@ -2205,7 +2242,7 @@ static void amd_iommu_iotlb_sync(struct iommu_domain *domain, unsigned long flags; spin_lock_irqsave(&dom->lock, flags); - __domain_flush_pages(dom, gather->start, gather->end - gather->start, 1); + domain_flush_pages(dom, gather->start, gather->end - gather->start, 1); amd_iommu_domain_flush_complete(dom); spin_unlock_irqrestore(&dom->lock, flags); } -- 2.25.1