mirror of
https://github.com/torvalds/linux
synced 2024-10-07 11:53:31 +00:00
421a511a29
IOMMU advertises Access/Dirty bits if the extended feature register reports it. Relevant AMD IOMMU SDM ref[0] "1.3.8 Enhanced Support for Access and Dirty Bits" To enable it set the DTE flag in bits 7 and 8 to enable access, or access+dirty. With that, the IOMMU starts marking the D and A flags on every Memory Request or ATS translation request. It is on the VMM side to steer whether to enable dirty tracking or not, rather than wrongly doing in IOMMU. Relevant AMD IOMMU SDM ref [0], "Table 7. Device Table Entry (DTE) Field Definitions" particularly the entry "HAD". To actually toggle on and off it's relatively simple as it's setting 2 bits on DTE and flush the device DTE cache. To get what's dirtied use existing AMD io-pgtable support, by walking the pagetables over each IOVA, with fetch_pte(). The IOTLB flushing is left to the caller (much like unmap), and iommu_dirty_bitmap_record() is the one adding page-ranges to invalidate. This allows caller to batch the flush over a big span of IOVA space, without the iommu wondering about when to flush. Worthwhile sections from AMD IOMMU SDM: "2.2.3.1 Host Access Support" "2.2.3.2 Host Dirty Support" For details on how IOMMU hardware updates the dirty bit see, and expects from its consequent clearing by CPU: "2.2.7.4 Updating Accessed and Dirty Bits in the Guest Address Tables" "2.2.7.5 Clearing Accessed and Dirty Bits" Quoting the SDM: "The setting of accessed and dirty status bits in the page tables is visible to both the CPU and the peripheral when sharing guest page tables. The IOMMU interlocked operations to update A and D bits must be 64-bit operations and naturally aligned on a 64-bit boundary" .. and for the IOMMU update sequence to Dirty bit, essentially is states: 1. Decodes the read and write intent from the memory access. 2. If P=0 in the page descriptor, fail the access. 3. Compare the A & D bits in the descriptor with the read and write intent in the request. 4. If the A or D bits need to be updated in the descriptor: * Start atomic operation. * Read the descriptor as a 64-bit access. * If the descriptor no longer appears to require an update, release the atomic lock with no further action and continue to step 5. * Calculate the new A & D bits. * Write the descriptor as a 64-bit access. * End atomic operation. 5. Continue to the next stage of translation or to the memory access. Access/Dirty bits readout also need to consider the non-default page-sizes (aka replicated PTEs as mentined by manual), as AMD supports all powers of two (except 512G) page sizes. Select IOMMUFD_DRIVER only if IOMMUFD is enabled considering that IOMMU dirty tracking requires IOMMUFD. Link: https://lore.kernel.org/r/20231024135109.73787-12-joao.m.martins@oracle.com Signed-off-by: Joao Martins <joao.m.martins@oracle.com> Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
46 lines
1.5 KiB
Plaintext
46 lines
1.5 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
# AMD IOMMU support
|
|
config AMD_IOMMU
|
|
bool "AMD IOMMU support"
|
|
select SWIOTLB
|
|
select PCI_MSI
|
|
select PCI_ATS
|
|
select PCI_PRI
|
|
select PCI_PASID
|
|
select IOMMU_API
|
|
select IOMMU_IOVA
|
|
select IOMMU_IO_PGTABLE
|
|
select IOMMUFD_DRIVER if IOMMUFD
|
|
depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE
|
|
help
|
|
With this option you can enable support for AMD IOMMU hardware in
|
|
your system. An IOMMU is a hardware component which provides
|
|
remapping of DMA memory accesses from devices. With an AMD IOMMU you
|
|
can isolate the DMA memory of different devices and protect the
|
|
system from misbehaving device drivers or hardware.
|
|
|
|
You can find out if your system has an AMD IOMMU if you look into
|
|
your BIOS for an option to enable it or if you have an IVRS ACPI
|
|
table.
|
|
|
|
config AMD_IOMMU_V2
|
|
tristate "AMD IOMMU Version 2 driver"
|
|
depends on AMD_IOMMU
|
|
select MMU_NOTIFIER
|
|
help
|
|
This option enables support for the AMD IOMMUv2 features of the IOMMU
|
|
hardware. Select this option if you want to use devices that support
|
|
the PCI PRI and PASID interface.
|
|
|
|
config AMD_IOMMU_DEBUGFS
|
|
bool "Enable AMD IOMMU internals in DebugFS"
|
|
depends on AMD_IOMMU && IOMMU_DEBUGFS
|
|
help
|
|
!!!WARNING!!! !!!WARNING!!! !!!WARNING!!! !!!WARNING!!!
|
|
|
|
DO NOT ENABLE THIS OPTION UNLESS YOU REALLY, -REALLY- KNOW WHAT YOU ARE DOING!!!
|
|
Exposes AMD IOMMU device internals in DebugFS.
|
|
|
|
This option is -NOT- intended for production environments, and should
|
|
not generally be enabled.
|