All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
	<joro@8bytes.org>, <will@kernel.org>, <dwmw2@infradead.org>,
	<baolu.lu@linux.intel.com>, <robin.murphy@arm.com>
Cc: <linux-kernel@vger.kernel.org>,
	<iommu@lists.linux-foundation.org>, <linuxarm@huawei.com>,
	<chenxiang66@hisilicon.com>
Subject: Re: [PATCH v10 1/3] iommu: Enhance IOMMU default DMA mode build options
Date: Fri, 4 Jun 2021 09:19:57 +0100	[thread overview]
Message-ID: <285ba65e-4c65-4320-13d9-60c4d72d82cb@huawei.com> (raw)
In-Reply-To: <0e54ff0f-c668-354e-1ec8-7536c701d3a8@huawei.com>


>>   
>>   	  If unsure, say N here.
>>   
>> +choice
>> +	prompt "IOMMU default DMA mode"
>> +	depends on IOMMU_API
> 
> config INTEL_IOMMU
>          depends on PCI_MSI && ACPI && (X86 || IA64)
> 
> config AMD_IOMMU
>          depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE
> 
> config ARM_SMMU_V3
>          depends on ARM64
> 
> "depends on ARM_SMMU_V3 || INTEL_IOMMU || AMD_IOMMU" may need to be added, because it doesn't work on other platforms.
> 
> or "depends on X86 || IA64 || X86_64 || ARM64"

I suppose so. But I don't think that any other archs use the value from 
iommu_dma_strict anyway.

> 
>> +
>> +	default IOMMU_DEFAULT_STRICT
>> +	help
>> +	  This option allows an IOMMU DMA mode to be chosen at build time, to
>> +	  override the default DMA mode of each ARCH, removing the need to
>> +	  pass in kernel parameters through command line. It is still possible
>> +	  to provide ARCH-specific or common boot options to override this
>> +	  option.
>> +
>> +	  If unsure, keep the default.
>> +
>> +config IOMMU_DEFAULT_LAZY
>> +	bool "lazy"
>> +	help
>> +	  Support lazy mode, where for every IOMMU DMA unmap operation, the
>> +	  flush operation of IOTLB and the free operation of IOVA are deferred.
>> +	  They are only guaranteed to be done before the related IOVA will be
>> +	  reused.
>> +
>> +config IOMMU_DEFAULT_STRICT
>> +	bool "strict"
>> +	help
>> +	  For every IOMMU DMA unmap operation, the flush operation of IOTLB and
>> +	  the free operation of IOVA are guaranteed to be done in the unmap
>> +	  function.
>> +
>> +	  This mode is safer than the two above, but it maybe slower in some
>> +	  high performace scenarios.
>> +
>> +endchoice
>> +
>>   config OF_IOMMU
>>   	def_bool y
>>   	depends on OF && IOMMU_API
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 966426a96520..177b0dafc535 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -29,7 +29,8 @@ static struct kset *iommu_group_kset;
>>   static DEFINE_IDA(iommu_group_ida);
>>   
>>   static unsigned int iommu_def_domain_type __read_mostly;
>> -static bool iommu_dma_strict __read_mostly = true;
>> +static bool iommu_dma_strict __read_mostly =
>> +			IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
> 
> Currently, a maximum of 100 columns are allowed in a row.

Sure, but some people still prefer limiting to 80, and codingstyle
doc mentions a preference for 80.

But if you really think I should change, then that's ok.

Thanks,
John

WARNING: multiple messages have this Message-ID
From: John Garry <john.garry@huawei.com>
To: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>,
	<joro@8bytes.org>, <will@kernel.org>, <dwmw2@infradead.org>,
	<baolu.lu@linux.intel.com>, <robin.murphy@arm.com>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com
Subject: Re: [PATCH v10 1/3] iommu: Enhance IOMMU default DMA mode build options
Date: Fri, 4 Jun 2021 09:19:57 +0100	[thread overview]
Message-ID: <285ba65e-4c65-4320-13d9-60c4d72d82cb@huawei.com> (raw)
In-Reply-To: <0e54ff0f-c668-354e-1ec8-7536c701d3a8@huawei.com>


>>   
>>   	  If unsure, say N here.
>>   
>> +choice
>> +	prompt "IOMMU default DMA mode"
>> +	depends on IOMMU_API
> 
> config INTEL_IOMMU
>          depends on PCI_MSI && ACPI && (X86 || IA64)
> 
> config AMD_IOMMU
>          depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE
> 
> config ARM_SMMU_V3
>          depends on ARM64
> 
> "depends on ARM_SMMU_V3 || INTEL_IOMMU || AMD_IOMMU" may need to be added, because it doesn't work on other platforms.
> 
> or "depends on X86 || IA64 || X86_64 || ARM64"

I suppose so. But I don't think that any other archs use the value from 
iommu_dma_strict anyway.

> 
>> +
>> +	default IOMMU_DEFAULT_STRICT
>> +	help
>> +	  This option allows an IOMMU DMA mode to be chosen at build time, to
>> +	  override the default DMA mode of each ARCH, removing the need to
>> +	  pass in kernel parameters through command line. It is still possible
>> +	  to provide ARCH-specific or common boot options to override this
>> +	  option.
>> +
>> +	  If unsure, keep the default.
>> +
>> +config IOMMU_DEFAULT_LAZY
>> +	bool "lazy"
>> +	help
>> +	  Support lazy mode, where for every IOMMU DMA unmap operation, the
>> +	  flush operation of IOTLB and the free operation of IOVA are deferred.
>> +	  They are only guaranteed to be done before the related IOVA will be
>> +	  reused.
>> +
>> +config IOMMU_DEFAULT_STRICT
>> +	bool "strict"
>> +	help
>> +	  For every IOMMU DMA unmap operation, the flush operation of IOTLB and
>> +	  the free operation of IOVA are guaranteed to be done in the unmap
>> +	  function.
>> +
>> +	  This mode is safer than the two above, but it maybe slower in some
>> +	  high performace scenarios.
>> +
>> +endchoice
>> +
>>   config OF_IOMMU
>>   	def_bool y
>>   	depends on OF && IOMMU_API
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index 966426a96520..177b0dafc535 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -29,7 +29,8 @@ static struct kset *iommu_group_kset;
>>   static DEFINE_IDA(iommu_group_ida);
>>   
>>   static unsigned int iommu_def_domain_type __read_mostly;
>> -static bool iommu_dma_strict __read_mostly = true;
>> +static bool iommu_dma_strict __read_mostly =
>> +			IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
> 
> Currently, a maximum of 100 columns are allowed in a row.

Sure, but some people still prefer limiting to 80, and codingstyle
doc mentions a preference for 80.

But if you really think I should change, then that's ok.

Thanks,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-06-04  8:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 13:58 [PATCH v10 0/3] Enhance IOMMU default DMA mode build options John Garry
2021-06-03 13:58 ` John Garry
2021-06-03 13:58 ` [PATCH v10 1/3] iommu: " John Garry
2021-06-03 13:58   ` John Garry
2021-06-03 17:00   ` Randy Dunlap
2021-06-03 17:00     ` Randy Dunlap
2021-06-03 17:04     ` John Garry
2021-06-03 17:04       ` John Garry
2021-06-04  2:54   ` Leizhen (ThunderTown)
2021-06-04  2:54     ` Leizhen (ThunderTown)
2021-06-04  8:19     ` John Garry [this message]
2021-06-04  8:19       ` John Garry
2021-06-03 13:58 ` [PATCH v10 2/3] iommu/vt-d: Add support for " John Garry
2021-06-03 13:58   ` John Garry
2021-06-03 13:58 ` [PATCH v10 3/3] iommu/amd: " John Garry
2021-06-03 13:58   ` John Garry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=285ba65e-4c65-4320-13d9-60c4d72d82cb@huawei.com \
    --to=john.garry@huawei.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chenxiang66@hisilicon.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.