On Tue, Jan 14, 2020 at 12:45:42PM +0000, Will Deacon wrote:
> On Thu, Dec 19, 2019 at 05:30:33PM +0100, Jean-Philippe Brucker wrote:
> > Enable PASID for PCI devices that support it. Since the SSID tables are
> > allocated by arm_smmu_attach_dev(), PASID has to be enabled early enough.
> > arm_smmu_dev_feature_enable() would be too late, since by that time the
>
> What is arm_smmu_dev_feature_enable()?
It's the implementation of the IOMMU op .dev_enable_feat(), which I'll add
later (called by a device driver to enable the SVA feature). I'll reword
this comment, since the only real requirement is enabling PASID before
ATS.
> > static void arm_smmu_detach_dev(struct arm_smmu_master *master)
> > {
> > unsigned long flags;
> > @@ -2852,13 +2899,16 @@ static int arm_smmu_add_device(struct device *dev)
> >
> > master->ssid_bits = min(smmu->ssid_bits, fwspec->num_pasid_bits);
> >
> > + /* Note that PASID must be enabled before, and disabled after ATS */
> > + arm_smmu_enable_pasid(master);
>
> Is that part of the PCIe specs? If so, please can you add a citation to the
> comment?
Yes (PCIe 4.0r1.0 10.5.1.3 ATS Control register).
> Are there any other ordering requirements, i.e. with respect to enabling
> substreams at the SMMU? For example, can a speculative ATS request provide
> a PASID?
You recent fix bfff88ec1afe ("iommu/arm-smmu-v3: Rework enabling/disabling
of ATS for PCI masters") should prevent from speculative ATS requests.
More generally both ATS and SSID are enabled and disabled at the same time
in the SMMU, when toggling STE.V, so any request arriving before STE
enablement will be aborted regardless of SSID.
Thanks,
Jean
