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@xxxxxxxxxx> >>>> >>>> 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.
