On Tue, Sep 08, 2020 at 11:38:31AM +0200, Auger Eric wrote: > Hi Jean, > On 8/17/20 7:15 PM, Jean-Philippe Brucker wrote: > > Aggregate all sanity-checks for sharing CPU page tables with the SMMU > > under a single ARM_SMMU_FEAT_SVA bit. For PCIe SVA, users also need to > > check FEAT_ATS and FEAT_PRI. For platform SVA, they will have to check > > FEAT_STALLS. > > > > Introduce ARM_SMMU_FEAT_BTM (Broadcast TLB Maintenance), but don't > > enable it at the moment. Since the entire VMID space is shared with the > > CPU, enabling DVM (by clearing SMMU_CR2.PTM) could result in > > over-invalidation and affect performance of stage-2 mappings. > In which series do you plan to enable it? In the third part, after the PRI+stall series. I still haven't had time to look at solving the stage-2 DVM problem (pinning VMIDs through KVM), so it might be a while. [...] > > + /* > > + * See max_pinned_asids in arch/arm64/mm/context.c. The following is > > + * generally the maximum number of bindable processes. > > + */ > > + if (IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0)) > Out of curiosity, What is the rationale behind using > arm64_kernel_unmapped_at_el0() versus > IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0)? > CPU caps being finalized? I'm not sure. The caps are finalized at this point. I'll change it. > Is that why you say "generally" here? I said "generally" because having less PASIDs than ASIDs is in theory possible, but hardware will normally support 20-bit PASIDs. > > + asid_bits--; > > + dev_dbg(smmu->dev, "%d shared contexts\n", (1 << asid_bits) -> + num_possible_cpus() - 2); > nit: s/shared/bindable? I find "shared" clearer, with regard to contexts Thanks, Jean