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

Joao Martins
2022-04-29T14:36:31Z

On 4/29/22 13:26, Robin Murphy wrote:
> 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.

Interesting, thanks for the clarification.