• Joao Martins's avatar
    iommu/amd: Access/Dirty bit support in IOPTEs · 421a511a
    Joao Martins authored
    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.comSigned-off-by: default avatarJoao Martins <joao.m.martins@oracle.com>
    Reviewed-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
    421a511a
Kconfig 1.49 KB