463f46e114
This branch has three new iommufd capabilities:
- Dirty tracking for DMA. AMD/ARM/Intel CPUs can now record if a DMA
writes to a page in the IOPTEs within the IO page table. This can be used
to generate a record of what memory is being dirtied by DMA activities
during a VM migration process. A VMM like qemu will combine the IOMMU
dirty bits with the CPU's dirty log to determine what memory to
transfer.
VFIO already has a DMA dirty tracking framework that requires PCI
devices to implement tracking HW internally. The iommufd version
provides an alternative that the VMM can select, if available. The two
are designed to have very similar APIs.
- Userspace controlled attributes for hardware page
tables (HWPT/iommu_domain). There are currently a few generic attributes
for HWPTs (support dirty tracking, and parent of a nest). This is an
entry point for the userspace iommu driver to control the HW in detail.
- Nested translation support for HWPTs. This is a 2D translation scheme
similar to the CPU where a DMA goes through a first stage to determine
an intermediate address which is then translated trough a second stage
to a physical address.
Like for CPU translation the first stage table would exist in VM
controlled memory and the second stage is in the kernel and matches the
VM's guest to physical map.
As every IOMMU has a unique set of parameter to describe the S1 IO page
table and its associated parameters the userspace IOMMU driver has to
marshal the information into the correct format.
This is 1/3 of the feature, it allows creating the nested translation
and binding it to VFIO devices, however the API to support IOTLB and
ATC invalidation of the stage 1 io page table, and forwarding of IO
faults are still in progress.
The series includes AMD and Intel support for dirty tracking. Intel
support for nested translation.
Along the way are a number of internal items:
- New iommu core items: ops->domain_alloc_user(), ops->set_dirty_tracking,
ops->read_and_clear_dirty(), IOMMU_DOMAIN_NESTED, and iommu_copy_struct_from_user
- UAF fix in iopt_area_split()
- Spelling fixes and some test suite improvement
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCZUDu2wAKCRCFwuHvBreF
YcdeAQDaBmjyGLrRIlzPyohF6FrombyWo2512n51Hs8IHR4IvQEA3oRNgQ2tsJRr
1UPuOqnOD5T/oVX6AkUPRBwanCUQwwM=
=nyJ3
-----END PGP SIGNATURE-----
Merge tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd
Pull iommufd updates from Jason Gunthorpe:
"This brings three new iommufd capabilities:
- Dirty tracking for DMA.
AMD/ARM/Intel CPUs can now record if a DMA writes to a page in the
IOPTEs within the IO page table. This can be used to generate a
record of what memory is being dirtied by DMA activities during a
VM migration process. A VMM like qemu will combine the IOMMU dirty
bits with the CPU's dirty log to determine what memory to transfer.
VFIO already has a DMA dirty tracking framework that requires PCI
devices to implement tracking HW internally. The iommufd version
provides an alternative that the VMM can select, if available. The
two are designed to have very similar APIs.
- Userspace controlled attributes for hardware page tables
(HWPT/iommu_domain). There are currently a few generic attributes
for HWPTs (support dirty tracking, and parent of a nest). This is
an entry point for the userspace iommu driver to control the HW in
detail.
- Nested translation support for HWPTs. This is a 2D translation
scheme similar to the CPU where a DMA goes through a first stage to
determine an intermediate address which is then translated trough a
second stage to a physical address.
Like for CPU translation the first stage table would exist in VM
controlled memory and the second stage is in the kernel and matches
the VM's guest to physical map.
As every IOMMU has a unique set of parameter to describe the S1 IO
page table and its associated parameters the userspace IOMMU driver
has to marshal the information into the correct format.
This is 1/3 of the feature, it allows creating the nested
translation and binding it to VFIO devices, however the API to
support IOTLB and ATC invalidation of the stage 1 io page table,
and forwarding of IO faults are still in progress.
The series includes AMD and Intel support for dirty tracking. Intel
support for nested translation.
Along the way are a number of internal items:
- New iommu core items: ops->domain_alloc_user(),
ops->set_dirty_tracking, ops->read_and_clear_dirty(),
IOMMU_DOMAIN_NESTED, and iommu_copy_struct_from_user
- UAF fix in iopt_area_split()
- Spelling fixes and some test suite improvement"
* tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: (52 commits)
iommufd: Organize the mock domain alloc functions closer to Joerg's tree
iommufd/selftest: Fix page-size check in iommufd_test_dirty()
iommufd: Add iopt_area_alloc()
iommufd: Fix missing update of domains_itree after splitting iopt_area
iommu/vt-d: Disallow read-only mappings to nest parent domain
iommu/vt-d: Add nested domain allocation
iommu/vt-d: Set the nested domain to a device
iommu/vt-d: Make domain attach helpers to be extern
iommu/vt-d: Add helper to setup pasid nested translation
iommu/vt-d: Add helper for nested domain allocation
iommu/vt-d: Extend dmar_domain to support nested domain
iommufd: Add data structure for Intel VT-d stage-1 domain allocation
iommu/vt-d: Enhance capability check for nested parent domain allocation
iommufd/selftest: Add coverage for IOMMU_HWPT_ALLOC with nested HWPTs
iommufd/selftest: Add nested domain allocation for mock domain
iommu: Add iommu_copy_struct_from_user helper
iommufd: Add a nested HW pagetable object
iommu: Pass in parent domain with user_data to domain_alloc_user op
iommufd: Share iommufd_hwpt_alloc with IOMMUFD_OBJ_HWPT_NESTED
iommufd: Derive iommufd_hwpt_paging from iommufd_hw_pagetable
...
111 lines
3.4 KiB
Plaintext
111 lines
3.4 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
# Intel IOMMU support
|
|
config DMAR_TABLE
|
|
bool
|
|
|
|
config DMAR_PERF
|
|
bool
|
|
|
|
config DMAR_DEBUG
|
|
bool
|
|
|
|
config INTEL_IOMMU
|
|
bool "Support for Intel IOMMU using DMA Remapping Devices"
|
|
depends on PCI_MSI && ACPI && X86
|
|
select DMA_OPS
|
|
select IOMMU_API
|
|
select IOMMU_IOVA
|
|
select IOMMUFD_DRIVER if IOMMUFD
|
|
select NEED_DMA_MAP_STATE
|
|
select DMAR_TABLE
|
|
select SWIOTLB
|
|
select PCI_ATS
|
|
select PCI_PRI
|
|
select PCI_PASID
|
|
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.
|
|
|
|
if INTEL_IOMMU
|
|
|
|
config INTEL_IOMMU_DEBUGFS
|
|
bool "Export Intel IOMMU internals in Debugfs"
|
|
depends on IOMMU_DEBUGFS
|
|
select DMAR_PERF
|
|
select DMAR_DEBUG
|
|
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 X86_64
|
|
select MMU_NOTIFIER
|
|
select IOMMU_SVA
|
|
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
|
|
bool "Enable Intel DMA Remapping Devices by default"
|
|
default y
|
|
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 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 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"
|
|
default y
|
|
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.
|
|
|
|
config INTEL_IOMMU_PERF_EVENTS
|
|
def_bool y
|
|
bool "Intel IOMMU performance events"
|
|
depends on INTEL_IOMMU && PERF_EVENTS
|
|
help
|
|
Selecting this option will enable the performance monitoring
|
|
infrastructure in the Intel IOMMU. It collects information about
|
|
key events occurring during operation of the remapping hardware,
|
|
to aid performance tuning and debug. These are available on modern
|
|
processors which support Intel VT-d 4.0 and later.
|
|
|
|
endif # INTEL_IOMMU
|