| Message ID | 3-v3-e2e16cd7467f+2a6a1-smmuv3_nesting_jgg@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Initial support for SMMUv3 nested translation | expand |
On 2024/10/10 0:23, Jason Gunthorpe wrote: > From: Nicolin Chen<nicolinc@nvidia.com> > > The IORT spec, Issue E.f (April 2024), adds a new CANWBS bit to the Memory > Access Flag field in the Memory Access Properties table, mainly for a PCI > Root Complex. > > This CANWBS defines the coherency of memory accesses to be not marked IOWB > cacheable/shareable. Its value further implies the coherency impact from a > pair of mismatched memory attributes (e.g. in a nested translation case): > 0x0: Use of mismatched memory attributes for accesses made by this > device may lead to a loss of coherency. > 0x1: Coherency of accesses made by this device to locations in > Conventional memory are ensured as follows, even if the memory > attributes for the accesses presented by the device or provided by > the SMMU are different from Inner and Outer Write-back cacheable, > Shareable. > > Note that the loss of coherency on a CANWBS-unsupported HW typically could > occur to an SMMU that doesn't implement the S2FWB feature where additional > cache flush operations would be required to prevent that from happening. > > Add a new ACPI_IORT_MF_CANWBS flag and set IOMMU_FWSPEC_PCI_RC_CANWBS upon > the presence of this new flag. > > CANWBS and S2FWB are similar features, in that they both guarantee the VM > can not violate coherency, however S2FWB can be bypassed by PCI No Snoop > TLPs, while CANWBS cannot. Thus CANWBS meets the requirements to set > IOMMU_CAP_ENFORCE_CACHE_COHERENCY. > > Architecturally ARM has expected that VFIO would disable No Snoop through > PCI Config space, if this is done then the two would have the same > protections. Acked-by: Hanjun Guo <guohanjun@huawei.com> Thanks Hanjun
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Thursday, October 10, 2024 12:23 AM > > From: Nicolin Chen <nicolinc@nvidia.com> > > The IORT spec, Issue E.f (April 2024), adds a new CANWBS bit to the Memory > Access Flag field in the Memory Access Properties table, mainly for a PCI > Root Complex. > > This CANWBS defines the coherency of memory accesses to be not marked > IOWB > cacheable/shareable. Its value further implies the coherency impact from a > pair of mismatched memory attributes (e.g. in a nested translation case): > 0x0: Use of mismatched memory attributes for accesses made by this > device may lead to a loss of coherency. > 0x1: Coherency of accesses made by this device to locations in > Conventional memory are ensured as follows, even if the memory > attributes for the accesses presented by the device or provided by > the SMMU are different from Inner and Outer Write-back cacheable, > Shareable. > > Note that the loss of coherency on a CANWBS-unsupported HW typically > could > occur to an SMMU that doesn't implement the S2FWB feature where > additional > cache flush operations would be required to prevent that from happening. > > Add a new ACPI_IORT_MF_CANWBS flag and set > IOMMU_FWSPEC_PCI_RC_CANWBS upon > the presence of this new flag. > > CANWBS and S2FWB are similar features, in that they both guarantee the VM > can not violate coherency, however S2FWB can be bypassed by PCI No Snoop > TLPs, while CANWBS cannot. Thus CANWBS meets the requirements to set > IOMMU_CAP_ENFORCE_CACHE_COHERENCY. > > Architecturally ARM has expected that VFIO would disable No Snoop through > PCI Config space, if this is done then the two would have the same > protections. > > Tested-by: Nicolin Chen <nicolinc@nvidia.com> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 4c745a26226b27..1f7e4c691d9ee3 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1218,6 +1218,17 @@ static bool iort_pci_rc_supports_ats(struct acpi_iort_node *node) return pci_rc->ats_attribute & ACPI_IORT_ATS_SUPPORTED; } +static bool iort_pci_rc_supports_canwbs(struct acpi_iort_node *node) +{ + struct acpi_iort_memory_access *memory_access; + struct acpi_iort_root_complex *pci_rc; + + pci_rc = (struct acpi_iort_root_complex *)node->node_data; + memory_access = + (struct acpi_iort_memory_access *)&pci_rc->memory_properties; + return memory_access->memory_flags & ACPI_IORT_MF_CANWBS; +} + static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node, u32 streamid) { @@ -1335,6 +1346,8 @@ int iort_iommu_configure_id(struct device *dev, const u32 *id_in) fwspec = dev_iommu_fwspec_get(dev); if (fwspec && iort_pci_rc_supports_ats(node)) fwspec->flags |= IOMMU_FWSPEC_PCI_RC_ATS; + if (fwspec && iort_pci_rc_supports_canwbs(node)) + fwspec->flags |= IOMMU_FWSPEC_PCI_RC_CANWBS; } else { node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT, iort_match_node_callback, dev); diff --git a/include/linux/iommu.h b/include/linux/iommu.h index c88d18d2c9280d..4ad9b9ec6c9b27 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -991,6 +991,8 @@ struct iommu_fwspec { /* ATS is supported */ #define IOMMU_FWSPEC_PCI_RC_ATS (1 << 0) +/* CANWBS is supported */ +#define IOMMU_FWSPEC_PCI_RC_CANWBS (1 << 1) /* * An iommu attach handle represents a relationship between an iommu domain