Skip to content
  • Peter Maydell's avatar
    f8e7163d
    hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2 · f8e7163d
    Peter Maydell authored
    
    
    The Arm SMMUv3 includes an optional feature equivalent to the CPU
    FEAT_BBM, which permits an OS to switch a range of memory between
    "covered by a huge page" and "covered by a sequence of normal pages"
    without having to engage in the traditional 'break-before-make'
    dance. (This is particularly important for the SMMU, because devices
    performing I/O through an SMMU are less likely to be able to cope with
    the window in the sequence where an access results in a translation
    fault.)  The SMMU spec explicitly notes that one of the valid ways to
    be a BBM level 2 compliant implementation is:
     * if there are multiple entries in the TLB for an address,
       choose one of them and use it, ignoring the others
    
    Our SMMU TLB implementation (unlike our CPU TLB) does allow multiple
    TLB entries for an address, because the translation table level is
    part of the SMMUIOTLBKey, and so our IOTLB hashtable can include
    entries for the same address where the leaf was at different levels
    (i.e. both hugepage and normal page). Our TLB lookup implementation in
    smmu_iotlb_lookup() will always find the entry with the lowest level
    (i.e. it prefers the hugepage over the normal page) and ignore any
    others. TLB invalidation correctly removes all TLB entries matching
    the specified address or address range (unless the guest specifies the
    leaf level explicitly, in which case it gets what it asked for). So we
    can validly advertise support for BBML level 2.
    
    Note that we still can't yet advertise ourselves as an SMMU v3.2,
    because v3.2 requires support for the S2FWB feature, which we don't
    yet implement.
    
    Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
    Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
    Message-id: 20220426160422.2353158-4-peter.maydell@linaro.org
    f8e7163d
    hw/arm/smmuv3: Advertise support for SMMUv3.2-BBML2
    Peter Maydell authored
    
    
    The Arm SMMUv3 includes an optional feature equivalent to the CPU
    FEAT_BBM, which permits an OS to switch a range of memory between
    "covered by a huge page" and "covered by a sequence of normal pages"
    without having to engage in the traditional 'break-before-make'
    dance. (This is particularly important for the SMMU, because devices
    performing I/O through an SMMU are less likely to be able to cope with
    the window in the sequence where an access results in a translation
    fault.)  The SMMU spec explicitly notes that one of the valid ways to
    be a BBM level 2 compliant implementation is:
     * if there are multiple entries in the TLB for an address,
       choose one of them and use it, ignoring the others
    
    Our SMMU TLB implementation (unlike our CPU TLB) does allow multiple
    TLB entries for an address, because the translation table level is
    part of the SMMUIOTLBKey, and so our IOTLB hashtable can include
    entries for the same address where the leaf was at different levels
    (i.e. both hugepage and normal page). Our TLB lookup implementation in
    smmu_iotlb_lookup() will always find the entry with the lowest level
    (i.e. it prefers the hugepage over the normal page) and ignore any
    others. TLB invalidation correctly removes all TLB entries matching
    the specified address or address range (unless the guest specifies the
    leaf level explicitly, in which case it gets what it asked for). So we
    can validly advertise support for BBML level 2.
    
    Note that we still can't yet advertise ourselves as an SMMU v3.2,
    because v3.2 requires support for the S2FWB feature, which we don't
    yet implement.
    
    Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
    Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
    Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
    Message-id: 20220426160422.2353158-4-peter.maydell@linaro.org
Loading