Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp778704pxj; Thu, 17 Jun 2021 13:44:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxgC6MgYqRt3qCwnXOHPtwIhIk79+o5l6RStE7/T7H9Z/lhhiexO1bwgh10UYarQ+tL8KQ X-Received: by 2002:aa7:cfd7:: with SMTP id r23mr239057edy.300.1623962658231; Thu, 17 Jun 2021 13:44:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623962658; cv=none; d=google.com; s=arc-20160816; b=ZhU4XC56ACjwoE5GwyTb2bI/9IzpKoJxAsBBGM2Mcjkk5HLR2l87SNz/8ogxwcdpn0 4haNq08Cf6vDB/QEL67VZQr19nxfQzwyjjFN+8Y26n3/J6+DLiEPAWxZ92qM82fNZDYW KboHeC3i0MWfPiO3uG2X3lIOj935MrjBoNRL6T2YYJyol7LXFlVBtZnn71SDW5RSxyih Ys6sSRIqxKC6BQwWOJc4uJ0ztBiuQzIUzIZICklwWbEJWzhaY1U73BFthicxQq+lQppA ahUoqJ9G0arkRXMRZl0/ysnjng3pnkbOYjUqyZAcggpLGs7TYfaG948Ez+jrPhFNEqKB WqtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=s1NQcAOCDEdj+KXY24djwQlXafOG3MkW2MiOlD2RqQc=; b=Ck7SUKgGm1oP67u/EATMUtb5k9JhKD2DKoneGfL2FLlRKKNnl9602c798tm4JVWn8h 0aE4TajKZ7fDmD5tcFtyf+eDGMiwLn2kPtiHU/tKLFHVFc4atoQSwKzukv+y0JUsPkiB Or0FpPRGGW7ZAoFKSNscSbDnJeDtHhlKcjHPQSOL6bHhYeqlZRo+2IVRNYILLj0tWwJZ jmfrWA1Z1psv+hd3KwVitO+DRyNCuSX7Xze0nSqYpf/em8ByJ5hfuhRTMceL6HkipIxA sPtKWatQRQB09NpUZhTftQe61gfaxqUy2xzqOr/aDWg9J0tRxBSJE4SSyd4i71hwcPI9 nSGA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q6si6850256edd.362.2021.06.17.13.43.54; Thu, 17 Jun 2021 13:44:18 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231853AbhFQTEO (ORCPT + 99 others); Thu, 17 Jun 2021 15:04:14 -0400 Received: from foss.arm.com ([217.140.110.172]:58634 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231403AbhFQTEN (ORCPT ); Thu, 17 Jun 2021 15:04:13 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4CFC013A1; Thu, 17 Jun 2021 12:02:05 -0700 (PDT) Received: from [10.57.9.136] (unknown [10.57.9.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 683143F694; Thu, 17 Jun 2021 12:02:03 -0700 (PDT) Subject: Re: [PATCH v13 1/6] iommu: Deprecate Intel and AMD cmdline methods to enable strict mode To: John Garry , joro@8bytes.org, will@kernel.org, dwmw2@infradead.org, baolu.lu@linux.intel.com, corbet@lwn.net Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linuxarm@huawei.com, thunder.leizhen@huawei.com, chenxiang66@hisilicon.com, linux-doc@vger.kernel.org References: <1623841437-211832-1-git-send-email-john.garry@huawei.com> <1623841437-211832-2-git-send-email-john.garry@huawei.com> From: Robin Murphy Message-ID: Date: Thu, 17 Jun 2021 20:01:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <1623841437-211832-2-git-send-email-john.garry@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-06-16 12:03, John Garry wrote: > Now that the x86 drivers support iommu.strict, deprecate the custom > methods. > > Signed-off-by: John Garry > --- > Documentation/admin-guide/kernel-parameters.txt | 5 +++-- > drivers/iommu/amd/init.c | 4 +++- > drivers/iommu/intel/iommu.c | 1 + > 3 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 30e9dd52464e..fcbb36d6eea7 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -290,7 +290,8 @@ > amd_iommu= [HW,X86-64] > Pass parameters to the AMD IOMMU driver in the system. > Possible values are: > - fullflush - enable flushing of IO/TLB entries when > + fullflush [Deprecated, use iommu.strict instead] > + - enable flushing of IO/TLB entries when > they are unmapped. Otherwise they are > flushed before they will be reused, which > is a lot of faster > @@ -1947,7 +1948,7 @@ > bypassed by not enabling DMAR with this option. In > this case, gfx device will use physical address for > DMA. > - strict [Default Off] > + strict [Default Off] [Deprecated, use iommu.strict instead] > With this option on every unmap_single operation will > result in a hardware IOTLB flush operation as opposed > to batching them for performance. FWIW I'd be inclined to replace both whole descriptions with just something like "Deprecated, equivalent to iommu.strict=1". > diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c > index 46280e6e1535..9f3096d650aa 100644 > --- a/drivers/iommu/amd/init.c > +++ b/drivers/iommu/amd/init.c > @@ -3098,8 +3098,10 @@ static int __init parse_amd_iommu_intr(char *str) > static int __init parse_amd_iommu_options(char *str) > { > for (; *str; ++str) { > - if (strncmp(str, "fullflush", 9) == 0) > + if (strncmp(str, "fullflush", 9) == 0) { > + pr_warn("amd_iommu=fullflush deprecated; use iommu.strict instead\n"); Nit: maybe we should spell out "...use