IOMMU Archive on lore.kernel.org
 help / color / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jerry Snitselaar <jsnitsel@redhat.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory
Date: Wed, 1 Jul 2020 09:49:54 +0800
Message-ID: <67b765e4-5285-a706-f32a-f5e1bc78c306@linux.intel.com> (raw)
In-Reply-To: <20200630200636.48600-2-jsnitsel@redhat.com>

Hi Jerry,

On 7/1/20 4:06 AM, Jerry Snitselaar wrote:
> Move Intel Kconfig and Makefile bits down into intel directory
> with the rest of the Intel specific files.
> 
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Lu Baolu <baolu.lu@linux.intel.com>

Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>

Best regards,
baolu

> Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
> ---
>   drivers/iommu/Kconfig        | 86 +-----------------------------------
>   drivers/iommu/Makefile       |  8 +---
>   drivers/iommu/intel/Kconfig  | 86 ++++++++++++++++++++++++++++++++++++
>   drivers/iommu/intel/Makefile |  7 +++
>   4 files changed, 96 insertions(+), 91 deletions(-)
>   create mode 100644 drivers/iommu/intel/Kconfig
>   create mode 100644 drivers/iommu/intel/Makefile
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 6dc49ed8377a..281cd6bd0fe0 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -176,91 +176,7 @@ config AMD_IOMMU_DEBUGFS
>   	  This option is -NOT- intended for production environments, and should
>   	  not generally be enabled.
>   
> -# Intel IOMMU support
> -config DMAR_TABLE
> -	bool
> -
> -config INTEL_IOMMU
> -	bool "Support for Intel IOMMU using DMA Remapping Devices"
> -	depends on PCI_MSI && ACPI && (X86 || IA64)
> -	select IOMMU_API
> -	select IOMMU_IOVA
> -	select NEED_DMA_MAP_STATE
> -	select DMAR_TABLE
> -	select SWIOTLB
> -	select IOASID
> -	help
> -	  DMA remapping (DMAR) devices support enables independent address
> -	  translations for Direct Memory Access (DMA) from devices.
> -	  These DMA remapping devices are reported via ACPI tables
> -	  and include PCI device scope covered by these DMA
> -	  remapping devices.
> -
> -config INTEL_IOMMU_DEBUGFS
> -	bool "Export Intel IOMMU internals in Debugfs"
> -	depends on INTEL_IOMMU && IOMMU_DEBUGFS
> -	help
> -	  !!!WARNING!!!
> -
> -	  DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!!!
> -
> -	  Expose Intel IOMMU internals in Debugfs.
> -
> -	  This option is -NOT- intended for production environments, and should
> -	  only be enabled for debugging Intel IOMMU.
> -
> -config INTEL_IOMMU_SVM
> -	bool "Support for Shared Virtual Memory with Intel IOMMU"
> -	depends on INTEL_IOMMU && X86_64
> -	select PCI_PASID
> -	select PCI_PRI
> -	select MMU_NOTIFIER
> -	select IOASID
> -	help
> -	  Shared Virtual Memory (SVM) provides a facility for devices
> -	  to access DMA resources through process address space by
> -	  means of a Process Address Space ID (PASID).
> -
> -config INTEL_IOMMU_DEFAULT_ON
> -	def_bool y
> -	prompt "Enable Intel DMA Remapping Devices by default"
> -	depends on INTEL_IOMMU
> -	help
> -	  Selecting this option will enable a DMAR device at boot time if
> -	  one is found. If this option is not selected, DMAR support can
> -	  be enabled by passing intel_iommu=on to the kernel.
> -
> -config INTEL_IOMMU_BROKEN_GFX_WA
> -	bool "Workaround broken graphics drivers (going away soon)"
> -	depends on INTEL_IOMMU && BROKEN && X86
> -	help
> -	  Current Graphics drivers tend to use physical address
> -	  for DMA and avoid using DMA APIs. Setting this config
> -	  option permits the IOMMU driver to set a unity map for
> -	  all the OS-visible memory. Hence the driver can continue
> -	  to use physical addresses for DMA, at least until this
> -	  option is removed in the 2.6.32 kernel.
> -
> -config INTEL_IOMMU_FLOPPY_WA
> -	def_bool y
> -	depends on INTEL_IOMMU && X86
> -	help
> -	  Floppy disk drivers are known to bypass DMA API calls
> -	  thereby failing to work when IOMMU is enabled. This
> -	  workaround will setup a 1:1 mapping for the first
> -	  16MiB to make floppy (an ISA device) work.
> -
> -config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> -	bool "Enable Intel IOMMU scalable mode by default"
> -	depends on INTEL_IOMMU
> -	help
> -	  Selecting this option will enable by default the scalable mode if
> -	  hardware presents the capability. The scalable mode is defined in
> -	  VT-d 3.0. The scalable mode capability could be checked by reading
> -	  /sys/devices/virtual/iommu/dmar*/intel-iommu/ecap. If this option
> -	  is not selected, scalable mode support could also be enabled by
> -	  passing intel_iommu=sm_on to the kernel. If not sure, please use
> -	  the default value.
> +source "drivers/iommu/intel/Kconfig"
>   
>   config IRQ_REMAP
>   	bool "Support for Interrupt Remapping"
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 342190196dfb..71dd2f382e78 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -1,4 +1,5 @@
>   # SPDX-License-Identifier: GPL-2.0
> +obj-y += intel/
>   obj-$(CONFIG_IOMMU_API) += iommu.o
>   obj-$(CONFIG_IOMMU_API) += iommu-traces.o
>   obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
> @@ -17,13 +18,8 @@ obj-$(CONFIG_AMD_IOMMU_V2) += amd/iommu_v2.o
>   obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
>   arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o
>   obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
> -obj-$(CONFIG_DMAR_TABLE) += intel/dmar.o
> -obj-$(CONFIG_INTEL_IOMMU) += intel/iommu.o intel/pasid.o
> -obj-$(CONFIG_INTEL_IOMMU) += intel/trace.o
> -obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += intel/debugfs.o
> -obj-$(CONFIG_INTEL_IOMMU_SVM) += intel/svm.o
>   obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
> -obj-$(CONFIG_IRQ_REMAP) += intel/irq_remapping.o irq_remapping.o
> +obj-$(CONFIG_IRQ_REMAP) += irq_remapping.o
>   obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
>   obj-$(CONFIG_MTK_IOMMU_V1) += mtk_iommu_v1.o
>   obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
> diff --git a/drivers/iommu/intel/Kconfig b/drivers/iommu/intel/Kconfig
> new file mode 100644
> index 000000000000..877beec9d987
> --- /dev/null
> +++ b/drivers/iommu/intel/Kconfig
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +# Intel IOMMU support
> +config DMAR_TABLE
> +	bool
> +
> +config INTEL_IOMMU
> +	bool "Support for Intel IOMMU using DMA Remapping Devices"
> +	depends on PCI_MSI && ACPI && (X86 || IA64)
> +	select IOMMU_API
> +	select IOMMU_IOVA
> +	select NEED_DMA_MAP_STATE
> +	select DMAR_TABLE
> +	select SWIOTLB
> +	select IOASID
> +	help
> +	  DMA remapping (DMAR) devices support enables independent address
> +	  translations for Direct Memory Access (DMA) from devices.
> +	  These DMA remapping devices are reported via ACPI tables
> +	  and include PCI device scope covered by these DMA
> +	  remapping devices.
> +
> +config INTEL_IOMMU_DEBUGFS
> +	bool "Export Intel IOMMU internals in Debugfs"
> +	depends on INTEL_IOMMU && IOMMU_DEBUGFS
> +	help
> +	  !!!WARNING!!!
> +
> +	  DO NOT ENABLE THIS OPTION UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!!!
> +
> +	  Expose Intel IOMMU internals in Debugfs.
> +
> +	  This option is -NOT- intended for production environments, and should
> +	  only be enabled for debugging Intel IOMMU.
> +
> +config INTEL_IOMMU_SVM
> +	bool "Support for Shared Virtual Memory with Intel IOMMU"
> +	depends on INTEL_IOMMU && X86_64
> +	select PCI_PASID
> +	select PCI_PRI
> +	select MMU_NOTIFIER
> +	select IOASID
> +	help
> +	  Shared Virtual Memory (SVM) provides a facility for devices
> +	  to access DMA resources through process address space by
> +	  means of a Process Address Space ID (PASID).
> +
> +config INTEL_IOMMU_DEFAULT_ON
> +	def_bool y
> +	prompt "Enable Intel DMA Remapping Devices by default"
> +	depends on INTEL_IOMMU
> +	help
> +	  Selecting this option will enable a DMAR device at boot time if
> +	  one is found. If this option is not selected, DMAR support can
> +	  be enabled by passing intel_iommu=on to the kernel.
> +
> +config INTEL_IOMMU_BROKEN_GFX_WA
> +	bool "Workaround broken graphics drivers (going away soon)"
> +	depends on INTEL_IOMMU && BROKEN && X86
> +	help
> +	  Current Graphics drivers tend to use physical address
> +	  for DMA and avoid using DMA APIs. Setting this config
> +	  option permits the IOMMU driver to set a unity map for
> +	  all the OS-visible memory. Hence the driver can continue
> +	  to use physical addresses for DMA, at least until this
> +	  option is removed in the 2.6.32 kernel.
> +
> +config INTEL_IOMMU_FLOPPY_WA
> +	def_bool y
> +	depends on INTEL_IOMMU && X86
> +	help
> +	  Floppy disk drivers are known to bypass DMA API calls
> +	  thereby failing to work when IOMMU is enabled. This
> +	  workaround will setup a 1:1 mapping for the first
> +	  16MiB to make floppy (an ISA device) work.
> +
> +config INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON
> +	bool "Enable Intel IOMMU scalable mode by default"
> +	depends on INTEL_IOMMU
> +	help
> +	  Selecting this option will enable by default the scalable mode if
> +	  hardware presents the capability. The scalable mode is defined in
> +	  VT-d 3.0. The scalable mode capability could be checked by reading
> +	  /sys/devices/virtual/iommu/dmar*/intel-iommu/ecap. If this option
> +	  is not selected, scalable mode support could also be enabled by
> +	  passing intel_iommu=sm_on to the kernel. If not sure, please use
> +	  the default value.
> diff --git a/drivers/iommu/intel/Makefile b/drivers/iommu/intel/Makefile
> new file mode 100644
> index 000000000000..fb8e1e8c8029
> --- /dev/null
> +++ b/drivers/iommu/intel/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_DMAR_TABLE) += dmar.o
> +obj-$(CONFIG_INTEL_IOMMU) += iommu.o pasid.o
> +obj-$(CONFIG_INTEL_IOMMU) += trace.o
> +obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += debugfs.o
> +obj-$(CONFIG_INTEL_IOMMU_SVM) += svm.o
> +obj-$(CONFIG_IRQ_REMAP) += irq_remapping.o
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 20:06 [PATCH v2 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories Jerry Snitselaar
2020-06-30 20:06 ` [PATCH v2 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory Jerry Snitselaar
2020-07-01  1:49   ` Lu Baolu [this message]
2020-06-30 20:06 ` [PATCH v2 2/2] iommu/amd: Move Kconfig and Makefile bits down into amd directory Jerry Snitselaar

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=67b765e4-5285-a706-f32a-f5e1bc78c306@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jsnitsel@redhat.com \
    --cc=linux-kernel@vger.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

IOMMU Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \
		iommu@lists.linux-foundation.org
	public-inbox-index linux-iommu

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git