Re: [PATCH RFC 13/19] iommu/arm-smmu-v3: Add feature detection for BBML

[Robin Murphy <robin.murphy@arm.com>]

On 2022-04-29 12:54, Joao Martins wrote:
> On 4/29/22 12:11, Robin Murphy wrote:
>> On 2022-04-28 22:09, Joao Martins wrote:
>>> From: Kunkun Jiang <jiangkunkun@huawei.com>
>>>
>>> This detects BBML feature and if SMMU supports it, transfer BBMLx
>>> quirk to io-pgtable.
>>>
>>> BBML1 requires still marking PTE nT prior to performing a
>>> translation table update, while BBML2 requires neither break-before-make
>>> nor PTE nT bit being set. For dirty tracking it needs to clear
>>> the dirty bit so checking BBML2 tells us the prerequisite. See SMMUv3.2
>>> manual, section "3.21.1.3 When SMMU_IDR3.BBML == 2 (Level 2)" and
>>> "3.21.1.2 When SMMU_IDR3.BBML == 1 (Level 1)"
>>
>> You can drop this, and the dependencies on BBML elsewhere, until you get
>> round to the future large-page-splitting work, since that's the only
>> thing this represents. Not much point having the feature flags without
>> an actual implementation, or any users.
>>
> OK.
> 
> My thinking was that the BBML2 meant *also* that we don't need that break-before-make
> thingie upon switching translation table entries. It seems that from what you
> say, BBML2 then just refers to this but only on the context of switching between
> hugepages/normal pages (?), not in general on all bits of the PTE (which we woud .. upon
> switching from writeable-dirty to writeable-clean with DBM-set).

Yes, BBML is purely about swapping between a block (hugepage) entry and 
a table representing the exact equivalent mapping.

A break-before-make procedure isn't required when just changing 
permissions, and AFAICS it doesn't apply to changing the DBM bit either, 
but as mentioned I think we could probably just not do that anyway.

Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu