On 3/16/22 20:37, Joao Martins wrote: > On 3/16/22 16:36, Joao Martins wrote: >> On 3/15/22 19:29, Jason Gunthorpe wrote: >>> On Fri, Mar 11, 2022 at 01:51:32PM +0000, Joao Martins wrote: >>>> On 2/28/22 13:01, Joao Martins wrote: >>>>> On 2/25/22 20:44, Jason Gunthorpe wrote: >>>>>> On Fri, Feb 25, 2022 at 07:18:37PM +0000, Joao Martins wrote: >>>>>>> On 2/23/22 01:03, Jason Gunthorpe wrote: >>>>>>>> On Tue, Feb 22, 2022 at 11:55:55AM +0000, Joao Martins wrote: >>>>>> Questions I have: >>>>>> - Do we need ranges for some reason? You mentioned ARM SMMU wants >>>>>> ranges? how/what/why? >>>>>> > > An amend here. > > Sigh, ARM turns out is slightly more unique compared to x86. As I am re-reviewing > the ARM side. Apparently you have two controls: one is a 'feature bit' > just like x86 and another is a modifier (arm-only). > > The Context descriptor (CD) equivalent to AMD DTEs or Intel context descriptor > equivalent for second-level. That's the top-level enabler to actually a *second* > modifier bit per-PTE (or per-TTD for more accurate terminology) which is the so > called DBM (dirty-bit-modifier). The latter when set, changes the meaning of > read/write access-flags of the PTE AP[2]. > > If you have CD.HD enabled (aka HTTU is enabled) *and* PTE.DBM set, then a > transition in the SMMU from "writable Clean" to "written" means that the the > access bits go from "read-only" (AP[2] = 1) to "read/write" (AP[2] = 0) > if-and-only-if PTE.DBM = 1 (and does not generate a permission IO page fault > like it normally would be with DBM = 0). Same thing for stage-2, except that > the access-bits are reversed (S2AP[1] is set when "written" and it's cleared > when it's "writable" (when DBM is also set). > > Now you could say that this allows you to control on a per-range basis. > Gah, no, more like a per-PTE basis is more accurate. > > And in practice I suppose that means that dynamically switching on/off SMMU > dirty-tracking *dynamically* means not only setting CD.HD but also walking the > page tables, and atomically setting/clearing both the DBM and AP[2]. > > References: > > DDI0487H, Table D5-30 Data access permissions > SMMU 3.2 spec, 3.13.3 Dirty flag hardware update I updated my branch and added an SMMUv3 implementation of the whole thing (slightly based on the past work) and adjusted the 'set tracking' structure to cover this slightly different h/w construct above. At the high-level we have 'set_dirty_tracking_range' API, which is internal in iommufd obviously. The UAPI won't change ofc. It's only compile-tested sadly as I have no SMMUv3.2 hardware, and to have this SMMUv3 DBM/HTTU support there's some requirements on the processor that I am not sure they can be fully emulated. The Intel iommu implementation follows same model as AMD and I will get to that next with a compliant iommu emulation too. But now, I will be focusing on hw_pagetable UAPI part. I understand your thinking of being tied to the hw_pagetable obj as opposed to IOAS for the dirty tracking APIs.
