Re: [PATCH v12 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
Hi Jean, On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote: > Some devices manage I/O Page Faults (IOPF) themselves instead of relying > on PCIe PRI or Arm SMMU stall. Allow their drivers to enable SVA without > mandating IOMMU-managed IOPF. The other device drivers now need to first > enable IOMMU_DEV_FEAT_IOPF before enabling IOMMU_DEV_FEAT_SVA. Enabling > IOMMU_DEV_FEAT_IOPF on its own doesn't have any effect visible to the > device driver, it is used in combination with other features. > > Signed-off-by: Jean-Philippe Brucker Reviewed-by: Eric Auger Eric > --- > Cc: Arnd Bergmann > Cc: David Woodhouse > Cc: Greg Kroah-Hartman > Cc: Joerg Roedel > Cc: Lu Baolu > Cc: Will Deacon > Cc: Zhangfei Gao > Cc: Zhou Wang > --- > include/linux/iommu.h | 20 +--- > 1 file changed, 17 insertions(+), 3 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index b7ea11fc1a93..00348e4c3c26 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -156,10 +156,24 @@ struct iommu_resv_region { > enum iommu_resv_typetype; > }; > > -/* Per device IOMMU features */ > +/** > + * enum iommu_dev_features - Per device IOMMU features > + * @IOMMU_DEV_FEAT_AUX: Auxiliary domain feature > + * @IOMMU_DEV_FEAT_SVA: Shared Virtual Addresses > + * @IOMMU_DEV_FEAT_IOPF: I/O Page Faults such as PRI or Stall. Generally > + *enabling %IOMMU_DEV_FEAT_SVA requires > + *%IOMMU_DEV_FEAT_IOPF, but some devices manage I/O Page > + *Faults themselves instead of relying on the IOMMU. When > + *supported, this feature must be enabled before and > + *disabled after %IOMMU_DEV_FEAT_SVA. > + * > + * Device drivers query whether a feature is supported using > + * iommu_dev_has_feature(), and enable it using iommu_dev_enable_feature(). > + */ > enum iommu_dev_features { > - IOMMU_DEV_FEAT_AUX, /* Aux-domain feature */ > - IOMMU_DEV_FEAT_SVA, /* Shared Virtual Addresses */ > + IOMMU_DEV_FEAT_AUX, > + IOMMU_DEV_FEAT_SVA, > + IOMMU_DEV_FEAT_IOPF, > }; > > #define IOMMU_PASID_INVALID (-1U) > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v12 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits
Hi, On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote: > The pasid-num-bits property shouldn't need a dedicated fwspec field, > it's a job for device properties. Add properties for IORT, and access > the number of PASID bits using device_property_read_u32(). > > Suggested-by: Robin Murphy > Acked-by: Jonathan Cameron > Signed-off-by: Jean-Philippe Brucker Reviewed-by: Eric Auger Eric > --- > include/linux/iommu.h | 2 -- > drivers/acpi/arm64/iort.c | 13 +++-- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++- > drivers/iommu/of_iommu.c| 5 - > 4 files changed, 9 insertions(+), 14 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index bdf3f34a4457..b7ea11fc1a93 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -571,7 +571,6 @@ struct iommu_group *fsl_mc_device_group(struct device > *dev); > * @ops: ops for this device's IOMMU > * @iommu_fwnode: firmware handle for this device's IOMMU > * @flags: IOMMU_FWSPEC_* flags > - * @num_pasid_bits: number of PASID bits supported by this device > * @num_ids: number of associated device IDs > * @ids: IDs which this device may present to the IOMMU > */ > @@ -579,7 +578,6 @@ struct iommu_fwspec { > const struct iommu_ops *ops; > struct fwnode_handle*iommu_fwnode; > u32 flags; > - u32 num_pasid_bits; > unsigned intnum_ids; > u32 ids[]; > }; > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c > index d4eac6d7e9fb..c9a8bbb74b09 100644 > --- a/drivers/acpi/arm64/iort.c > +++ b/drivers/acpi/arm64/iort.c > @@ -968,15 +968,16 @@ static int iort_pci_iommu_init(struct pci_dev *pdev, > u16 alias, void *data) > static void iort_named_component_init(struct device *dev, > struct acpi_iort_node *node) > { > + struct property_entry props[2] = {}; > struct acpi_iort_named_component *nc; > - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > - > - if (!fwspec) > - return; > > nc = (struct acpi_iort_named_component *)node->node_data; > - fwspec->num_pasid_bits = FIELD_GET(ACPI_IORT_NC_PASID_BITS, > -nc->node_flags); > + props[0] = PROPERTY_ENTRY_U32("pasid-num-bits", > + FIELD_GET(ACPI_IORT_NC_PASID_BITS, > + nc->node_flags)); > + > + if (device_add_properties(dev, props)) > + dev_warn(dev, "Could not add device properties\n"); > } > > static int iort_nc_iommu_map(struct device *dev, struct acpi_iort_node *node) > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index baebaac34a83..88dd9feb32f4 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -2392,7 +2392,8 @@ static struct iommu_device > *arm_smmu_probe_device(struct device *dev) > } > } > > - master->ssid_bits = min(smmu->ssid_bits, fwspec->num_pasid_bits); > + device_property_read_u32(dev, "pasid-num-bits", &master->ssid_bits); > + master->ssid_bits = min(smmu->ssid_bits, master->ssid_bits); > > /* >* Note that PASID must be enabled before, and disabled after ATS: > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index e505b9130a1c..a9d2df001149 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -210,11 +210,6 @@ const struct iommu_ops *of_iommu_configure(struct device > *dev, >of_pci_iommu_init, &info); > } else { > err = of_iommu_configure_device(master_np, dev, id); > - > - fwspec = dev_iommu_fwspec_get(dev); > - if (!err && fwspec) > - of_property_read_u32(master_np, "pasid-num-bits", > - &fwspec->num_pasid_bits); > } > > /* > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v12 08/10] dt-bindings: document stall property for IOMMU masters
Hi Jean-Philippe, On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote: > On ARM systems, some platform devices behind an IOMMU may support stall, > which is the ability to recover from page faults. Let the firmware tell us > when a device supports stall. > > Reviewed-by: Rob Herring > Signed-off-by: Jean-Philippe Brucker Reviewed-by: Eric Auger Eric > --- > .../devicetree/bindings/iommu/iommu.txt| 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt > b/Documentation/devicetree/bindings/iommu/iommu.txt > index 3c36334e4f94..26ba9e530f13 100644 > --- a/Documentation/devicetree/bindings/iommu/iommu.txt > +++ b/Documentation/devicetree/bindings/iommu/iommu.txt > @@ -92,6 +92,24 @@ Optional properties: >tagging DMA transactions with an address space identifier. By default, >this is 0, which means that the device only has one address space. > > +- dma-can-stall: When present, the master can wait for a transaction to > + complete for an indefinite amount of time. Upon translation fault some > + IOMMUs, instead of aborting the translation immediately, may first > + notify the driver and keep the transaction in flight. This allows the OS > + to inspect the fault and, for example, make physical pages resident > + before updating the mappings and completing the transaction. Such IOMMU > + accepts a limited number of simultaneous stalled transactions before > + having to either put back-pressure on the master, or abort new faulting > + transactions. > + > + Firmware has to opt-in stalling, because most buses and masters don't > + support it. In particular it isn't compatible with PCI, where > + transactions have to complete before a time limit. More generally it > + won't work in systems and masters that haven't been designed for > + stalling. For example the OS, in order to handle a stalled transaction, > + may attempt to retrieve pages from secondary storage in a stalled > + domain, leading to a deadlock. > + > > Notes: > == > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 06/27] dt-bindings: mediatek: Add binding for mt8192 IOMMU
On Fri, 2021-01-29 at 20:45 +0900, Tomasz Figa wrote: > On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote: > > > > On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote: > > > On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote: > > > > > > > > On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote: > > > > > On Wed, Jan 13, 2021 at 3:45 PM Yong Wu wrote: > > > > > > > > > > > > On Wed, 2021-01-13 at 14:30 +0900, Tomasz Figa wrote: > > > > > > > On Thu, Dec 24, 2020 at 8:35 PM Yong Wu > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, 2020-12-23 at 17:18 +0900, Tomasz Figa wrote: > > > > > > > > > On Wed, Dec 09, 2020 at 04:00:41PM +0800, Yong Wu wrote: > > > > > > > > > > This patch adds decriptions for mt8192 IOMMU and SMI. > > > > > > > > > > > > > > > > > > > > mt8192 also is MTK IOMMU gen2 which uses ARM > > > > > > > > > > Short-Descriptor translation > > > > > > > > > > table format. The M4U-SMI HW diagram is as below: > > > > > > > > > > > > > > > > > > > > EMI > > > > > > > > > >| > > > > > > > > > > M4U > > > > > > > > > >| > > > > > > > > > > > > > > > > > > > >SMI Common > > > > > > > > > > > > > > > > > > > >| > > > > > > > > > > +---+--+--+--+---+ > > > > > > > > > > | | | | .. | | > > > > > > > > > > | | | | | | > > > > > > > > > > larb0 larb1 larb2 larb4 .. larb19 larb20 > > > > > > > > > > disp0 disp1 mdpvdec IPE IPE > > > > > > > > > > > > > > > > > > > > All the connections are HW fixed, SW can NOT adjust it. > > > > > > > > > > > > > > > > > > > > mt8192 M4U support 0~16GB iova range. we preassign > > > > > > > > > > different engines > > > > > > > > > > into different iova ranges: > > > > > > > > > > > > > > > > > > > > domain-id module iova-range larbs > > > > > > > > > >0 disp0 ~ 4G larb0/1 > > > > > > > > > >1 vcodec 4G ~ 8G larb4/5/7 > > > > > > > > > >2 cam/mdp 8G ~ 12G > > > > > > > > > > larb2/9/11/13/14/16/17/18/19/20 > > > > > > > > > > > > > > > > > > Why do we preassign these addresses in DT? Shouldn't it be a > > > > > > > > > user's or > > > > > > > > > integrator's decision to split the 16 GB address range into > > > > > > > > > sub-ranges > > > > > > > > > and define which larbs those sub-ranges are shared with? > > > > > > > > > > > > > > > > The problem is that we can't split the 16GB range with the larb > > > > > > > > as unit. > > > > > > > > The example is the below ccu0(larb13 port9/10) is a independent > > > > > > > > range(domain), the others ports in larb13 is in another domain. > > > > > > > > > > > > > > > > disp/vcodec/cam/mdp don't have special iova requirement, they > > > > > > > > could > > > > > > > > access any range. vcodec also can locate 8G~12G. it don't care > > > > > > > > about > > > > > > > > where its iova locate. here I preassign like this following > > > > > > > > with our > > > > > > > > internal project setting. > > > > > > > > > > > > > > Let me try to understand this a bit more. Given the split you're > > > > > > > proposing, is there actually any isolation enforced between > > > > > > > particular > > > > > > > domains? For example, if I program vcodec to with a DMA address > > > > > > > from > > > > > > > the 0-4G range, would the IOMMU actually generate a fault, even if > > > > > > > disp had some memory mapped at that address? > > > > > > > > > > > > In this case. we will get fault in current SW setting. > > > > > > > > > > > > > > > > Okay, thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Why set this in DT?, this is only for simplifying the code. > > > > > > > > Assume we > > > > > > > > put it in the platform data. We have up to 32 larbs, each larb > > > > > > > > has up to > > > > > > > > 32 ports, each port may be in different iommu domains. we > > > > > > > > should have a > > > > > > > > big array for this..however we only use a macro to get the > > > > > > > > domain in the > > > > > > > > DT method. > > > > > > > > > > > > > > > > When replying this mail, I happen to see there is a > > > > > > > > "dev->dev_range_map" > > > > > > > > which has "dma-range" information, I think I could use this > > > > > > > > value to get > > > > > > > > which domain the device belong to. then no need put domid in > > > > > > > > DT. I will > > > > > > > > test this. > > > > > > > > > > > > > > My feeling is that the only part that needs to be enforced > > > > > > > statically > > > > > > > is the reserved IOVA range for CCUs. The other ranges should be > > > > > > > determined dynamically, al
Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
On 2021/1/27 23:43, Jean-Philippe Brucker wrote: > The SMMU provides a Stall model for handling page faults in platform > devices. It is similar to PCIe PRI, but doesn't require devices to have > their own translation cache. Instead, faulting transactions are parked > and the OS is given a chance to fix the page tables and retry the > transaction. > > Enable stall for devices that support it (opt-in by firmware). When an > event corresponds to a translation error, call the IOMMU fault handler. > If the fault is recoverable, it will call us back to terminate or > continue the stall. > > To use stall device drivers need to enable IOMMU_DEV_FEAT_IOPF, which > initializes the fault queue for the device. > > Tested-by: Zhangfei Gao > Reviewed-by: Jonathan Cameron > Signed-off-by: Jean-Philippe Brucker > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 43 > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 59 +- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 189 +- > 3 files changed, 276 insertions(+), 15 deletions(-) > [...] > @@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain > *smmu_domain, int ssid, > FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) | > CTXDESC_CD_0_V; > > - /* STALL_MODEL==0b10 && CD.S==0 is ILLEGAL */ > - if (smmu->features & ARM_SMMU_FEAT_STALL_FORCE) > + if (smmu_domain->stall_enabled) Could we add ssid checking here? like: if (smmu_domain->stall_enabled && ssid). The reason is if not CD.S will also be set when ssid is 0, which is not needed. Best, Zhou > val |= CTXDESC_CD_0_S; > } > > @@ -1278,7 +1320,7 @@ static void arm_smmu_write_strtab_ent(struct > arm_smmu_master *master, u32 sid, >FIELD_PREP(STRTAB_STE_1_STRW, strw)); > > if (smmu->features & ARM_SMMU_FEAT_STALLS && > -!(smmu->features & ARM_SMMU_FEAT_STALL_FORCE)) > + !master->stall_enabled) > dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD); > > val |= (s1_cfg->cdcfg.cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) | [...] ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v12 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Hi Jean, Some rather minor comments§questions below that may not justify a respin. On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote: > The SMMU provides a Stall model for handling page faults in platform > devices. It is similar to PCIe PRI, but doesn't require devices to have > their own translation cache. Instead, faulting transactions are parked > and the OS is given a chance to fix the page tables and retry the > transaction. > > Enable stall for devices that support it (opt-in by firmware). When an > event corresponds to a translation error, call the IOMMU fault handler. > If the fault is recoverable, it will call us back to terminate or > continue the stall. > > To use stall device drivers need to enable IOMMU_DEV_FEAT_IOPF, which > initializes the fault queue for the device. > > Tested-by: Zhangfei Gao > Reviewed-by: Jonathan Cameron > Signed-off-by: Jean-Philippe Brucker > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 43 > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 59 +- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 189 +- > 3 files changed, 276 insertions(+), 15 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h > index 7b15b7580c6e..59af0bbd2f7b 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h > @@ -354,6 +354,13 @@ > #define CMDQ_PRI_1_GRPID GENMASK_ULL(8, 0) > #define CMDQ_PRI_1_RESP GENMASK_ULL(13, 12) > > +#define CMDQ_RESUME_0_RESP_TERM 0UL > +#define CMDQ_RESUME_0_RESP_RETRY 1UL > +#define CMDQ_RESUME_0_RESP_ABORT 2UL > +#define CMDQ_RESUME_0_RESP GENMASK_ULL(13, 12) > +#define CMDQ_RESUME_0_SIDGENMASK_ULL(63, 32) > +#define CMDQ_RESUME_1_STAG GENMASK_ULL(15, 0) > + > #define CMDQ_SYNC_0_CS GENMASK_ULL(13, 12) > #define CMDQ_SYNC_0_CS_NONE 0 > #define CMDQ_SYNC_0_CS_IRQ 1 > @@ -370,6 +377,25 @@ > > #define EVTQ_0_IDGENMASK_ULL(7, 0) > > +#define EVT_ID_TRANSLATION_FAULT 0x10 > +#define EVT_ID_ADDR_SIZE_FAULT 0x11 > +#define EVT_ID_ACCESS_FAULT 0x12 > +#define EVT_ID_PERMISSION_FAULT 0x13 > + > +#define EVTQ_0_SSV (1UL << 11) > +#define EVTQ_0_SSID GENMASK_ULL(31, 12) > +#define EVTQ_0_SID GENMASK_ULL(63, 32) > +#define EVTQ_1_STAG GENMASK_ULL(15, 0) > +#define EVTQ_1_STALL (1UL << 31) > +#define EVTQ_1_PnU (1UL << 33) > +#define EVTQ_1_InD (1UL << 34) > +#define EVTQ_1_RnW (1UL << 35) > +#define EVTQ_1_S2(1UL << 39) > +#define EVTQ_1_CLASS GENMASK_ULL(41, 40) > +#define EVTQ_1_TT_READ (1UL << 44) > +#define EVTQ_2_ADDR GENMASK_ULL(63, 0) > +#define EVTQ_3_IPA GENMASK_ULL(51, 12) > + > /* PRI queue */ > #define PRIQ_ENT_SZ_SHIFT4 > #define PRIQ_ENT_DWORDS ((1 << PRIQ_ENT_SZ_SHIFT) >> 3) > @@ -464,6 +490,13 @@ struct arm_smmu_cmdq_ent { > enum pri_resp resp; > } pri; > > + #define CMDQ_OP_RESUME 0x44 > + struct { > + u32 sid; > + u16 stag; > + u8 resp; > + } resume; > + > #define CMDQ_OP_CMD_SYNC0x46 > struct { > u64 msiaddr; > @@ -522,6 +555,7 @@ struct arm_smmu_cmdq_batch { > > struct arm_smmu_evtq { > struct arm_smmu_queue q; > + struct iopf_queue *iopf; > u32 max_stalls; > }; > > @@ -659,7 +693,9 @@ struct arm_smmu_master { > struct arm_smmu_stream *streams; > unsigned intnum_streams; > boolats_enabled; > + boolstall_enabled; > boolsva_enabled; > + booliopf_enabled; > struct list_headbonds; > unsigned intssid_bits; > }; > @@ -678,6 +714,7 @@ struct arm_smmu_domain { > > struct io_pgtable_ops *pgtbl_ops; > boolnon_strict; > + boolstall_enabled; > atomic_tnr_ats_masters; > > enum arm_smmu_domain_stage stage; > @@ -719,6 +756,7 @@ bool arm_smmu_master_sva_supported(struct arm_smmu_master > *master); > bool arm_smmu_master_sva_enabled(struct arm_smmu_master *master); > int arm_smmu_master_enable_sva(struct arm_smmu_master *master); > int arm_
Re: [PATCH v12 06/10] iommu: Add a page fault handler
Hi Jean, On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote: > Some systems allow devices to handle I/O Page Faults in the core mm. For > example systems implementing the PCIe PRI extension or Arm SMMU stall > model. Infrastructure for reporting these recoverable page faults was > added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device > fault report API"). Add a page fault handler for host SVA. > > IOMMU driver can now instantiate several fault workqueues and link them > to IOPF-capable devices. Drivers can choose between a single global > workqueue, one per IOMMU device, one per low-level fault queue, one per > domain, etc. > > When it receives a fault event, most commonly in an IRQ handler, the > IOMMU driver reports the fault using iommu_report_device_fault(), which > calls the registered handler. The page fault handler then calls the mm > fault handler, and reports either success or failure with > iommu_page_response(). After the handler succeeds, the hardware retries > the access. > > The iopf_param pointer could be embedded into iommu_fault_param. But > putting iopf_param into the iommu_param structure allows us not to care > about ordering between calls to iopf_queue_add_device() and > iommu_register_device_fault_handler(). > > Reviewed-by: Jonathan Cameron > Signed-off-by: Jean-Philippe Brucker Reviewed-by: Eric Auger Thanks Eric > --- > drivers/iommu/Makefile| 1 + > drivers/iommu/iommu-sva-lib.h | 53 > include/linux/iommu.h | 2 + > drivers/iommu/io-pgfault.c| 461 ++ > 4 files changed, 517 insertions(+) > create mode 100644 drivers/iommu/io-pgfault.c > > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile > index 61bd30cd8369..60fafc23dee6 100644 > --- a/drivers/iommu/Makefile > +++ b/drivers/iommu/Makefile > @@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o > obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o > obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o > obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o > +obj-$(CONFIG_IOMMU_SVA_LIB) += io-pgfault.o > diff --git a/drivers/iommu/iommu-sva-lib.h b/drivers/iommu/iommu-sva-lib.h > index b40990aef3fd..031155010ca8 100644 > --- a/drivers/iommu/iommu-sva-lib.h > +++ b/drivers/iommu/iommu-sva-lib.h > @@ -12,4 +12,57 @@ int iommu_sva_alloc_pasid(struct mm_struct *mm, ioasid_t > min, ioasid_t max); > void iommu_sva_free_pasid(struct mm_struct *mm); > struct mm_struct *iommu_sva_find(ioasid_t pasid); > > +/* I/O Page fault */ > +struct device; > +struct iommu_fault; > +struct iopf_queue; > + > +#ifdef CONFIG_IOMMU_SVA_LIB > +int iommu_queue_iopf(struct iommu_fault *fault, void *cookie); > + > +int iopf_queue_add_device(struct iopf_queue *queue, struct device *dev); > +int iopf_queue_remove_device(struct iopf_queue *queue, > + struct device *dev); > +int iopf_queue_flush_dev(struct device *dev); > +struct iopf_queue *iopf_queue_alloc(const char *name); > +void iopf_queue_free(struct iopf_queue *queue); > +int iopf_queue_discard_partial(struct iopf_queue *queue); > + > +#else /* CONFIG_IOMMU_SVA_LIB */ > +static inline int iommu_queue_iopf(struct iommu_fault *fault, void *cookie) > +{ > + return -ENODEV; > +} > + > +static inline int iopf_queue_add_device(struct iopf_queue *queue, > + struct device *dev) > +{ > + return -ENODEV; > +} > + > +static inline int iopf_queue_remove_device(struct iopf_queue *queue, > +struct device *dev) > +{ > + return -ENODEV; > +} > + > +static inline int iopf_queue_flush_dev(struct device *dev) > +{ > + return -ENODEV; > +} > + > +static inline struct iopf_queue *iopf_queue_alloc(const char *name) > +{ > + return NULL; > +} > + > +static inline void iopf_queue_free(struct iopf_queue *queue) > +{ > +} > + > +static inline int iopf_queue_discard_partial(struct iopf_queue *queue) > +{ > + return -ENODEV; > +} > +#endif /* CONFIG_IOMMU_SVA_LIB */ > #endif /* _IOMMU_SVA_LIB_H */ > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 00348e4c3c26..edc9be443a74 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -366,6 +366,7 @@ struct iommu_fault_param { > * struct dev_iommu - Collection of per-device IOMMU data > * > * @fault_param: IOMMU detected device fault reporting data > + * @iopf_param: I/O Page Fault queue and data > * @fwspec: IOMMU fwspec data > * @iommu_dev:IOMMU device this device is linked to > * @priv: IOMMU Driver private data > @@ -376,6 +377,7 @@ struct iommu_fault_param { > struct dev_iommu { > struct mutex lock; > struct iommu_fault_param*fault_param; > + struct iopf_device_param*iopf_param; > struct iommu_fwspec *fwspec; > struct iommu_device *iommu_dev; > void*priv; > diff --git a/drivers/iommu/io-pgfault.c b/dri
Re: [PATCH 1/1] iommu/vt-d: Add qi_submit trace event
Lu Baolu writes: > This adds a new trace event to track the submissions of requests to the > invalidation queue. This event will provide the information like: > - IOMMU name > - Invalidation type > - Descriptor raw data > > A sample output like: > | qi_submit: iotlb_inv dmar1: 0x100e2 0x0 0x0 0x0 > | qi_submit: dev_tlb_inv dmar1: 0x13 0x7001 0x0 0x0 > | qi_submit: iotlb_inv dmar2: 0x800f2 0xf9a5 0x0 0x0 > > This will be helpful for queued invalidation related debugging. > > Signed-off-by: Lu Baolu While compiling current linux-next for some other test I noticed a compiler error because of this patch: drivers/iommu/intel/dmar.c: In function ‘qi_submit_sync’: drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function ‘trace_qi_submit’ [-Werror=implicit-function-declaration] 1311 | trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1, | ^~~ cc1: some warnings being treated as errors On my machine CONFIG_INTEL_IOMMU is not set so #include cannot provide the prototype for that function. Dirk > --- > drivers/iommu/intel/dmar.c | 3 +++ > include/trace/events/intel_iommu.h | 37 ++ > 2 files changed, 40 insertions(+) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index 004feaed3c72..bd51f33642e0 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > > #include "../irq_remapping.h" > > @@ -1307,6 +1308,8 @@ int qi_submit_sync(struct intel_iommu *iommu, struct > qi_desc *desc, > offset = ((index + i) % QI_LENGTH) << shift; > memcpy(qi->desc + offset, &desc[i], 1 << shift); > qi->desc_status[(index + i) % QI_LENGTH] = QI_IN_USE; > + trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1, > + desc[i].qw2, desc[i].qw3); > } > qi->desc_status[wait_index] = QI_IN_USE; > > diff --git a/include/trace/events/intel_iommu.h > b/include/trace/events/intel_iommu.h > index 112bd06487bf..aad2ff0c1e2e 100644 > --- a/include/trace/events/intel_iommu.h > +++ b/include/trace/events/intel_iommu.h > @@ -135,6 +135,43 @@ DEFINE_EVENT(dma_map_sg, bounce_map_sg, >struct scatterlist *sg), > TP_ARGS(dev, index, total, sg) > ); > + > +TRACE_EVENT(qi_submit, > + TP_PROTO(struct intel_iommu *iommu, u64 qw0, u64 qw1, u64 qw2, u64 qw3), > + > + TP_ARGS(iommu, qw0, qw1, qw2, qw3), > + > + TP_STRUCT__entry( > + __field(u64, qw0) > + __field(u64, qw1) > + __field(u64, qw2) > + __field(u64, qw3) > + __string(iommu, iommu->name) > + ), > + > + TP_fast_assign( > + __assign_str(iommu, iommu->name); > + __entry->qw0 = qw0; > + __entry->qw1 = qw1; > + __entry->qw2 = qw2; > + __entry->qw3 = qw3; > + ), > + > + TP_printk("%s %s: 0x%llx 0x%llx 0x%llx 0x%llx", > + __print_symbolic(__entry->qw0 & 0xf, > +{ QI_CC_TYPE,"cc_inv" }, > +{ QI_IOTLB_TYPE, "iotlb_inv" }, > +{ QI_DIOTLB_TYPE,"dev_tlb_inv" }, > +{ QI_IEC_TYPE, "iec_inv" }, > +{ QI_IWD_TYPE, "inv_wait" }, > +{ QI_EIOTLB_TYPE,"p_iotlb_inv" }, > +{ QI_PC_TYPE,"pc_inv" }, > +{ QI_DEIOTLB_TYPE, "p_dev_tlb_inv" }, > +{ QI_PGRP_RESP_TYPE, "page_grp_resp" }), > + __get_str(iommu), > + __entry->qw0, __entry->qw1, __entry->qw2, __entry->qw3 > + ) > +); > #endif /* _TRACE_INTEL_IOMMU_H */ > > /* This part must be outside protection */ ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu