From: Nicolin Chen <nicolinc@nvidia.com> To: Robin Murphy <robin.murphy@arm.com> Cc: <jgg@nvidia.com>, <will@kernel.org>, <eric.auger@redhat.com>, <kevin.tian@intel.com>, <baolu.lu@linux.intel.com>, <joro@8bytes.org>, <shameerali.kolothum.thodi@huawei.com>, <jean-philippe@linaro.org>, <linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user Date: Thu, 9 Mar 2023 19:51:21 -0800 [thread overview] Message-ID: <ZAqpOQ+DDvEfq0Dg@Asurada-Nvidia> (raw) In-Reply-To: <1467e666-1b6c-c285-3f79-f8e8b088718b@arm.com> On Thu, Mar 09, 2023 at 02:49:14PM +0000, Robin Murphy wrote: > External email: Use caution opening links or attachments > > > On 2023-03-09 10:53, Nicolin Chen wrote: > > Add arm_smmu_cache_invalidate_user() function for user space to invalidate > > TLB entries and Context Descriptors, since either an IO page table entrie > > or a Context Descriptor in the user space is still cached by the hardware. > > > > The input user_data is defined in "struct iommu_hwpt_invalidate_arm_smmuv3" > > that contains the essential data for corresponding invalidation commands. > > > > Co-developed-by: Eric Auger <eric.auger@redhat.com> > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > > --- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 56 +++++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > > > 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 ac63185ae268..7d73eab5e7f4 100644 > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > @@ -2880,9 +2880,65 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid) > > arm_smmu_sva_remove_dev_pasid(domain, dev, pasid); > > } > > > > +static void arm_smmu_cache_invalidate_user(struct iommu_domain *domain, > > + void *user_data) > > +{ > > + struct iommu_hwpt_invalidate_arm_smmuv3 *inv_info = user_data; > > + struct arm_smmu_cmdq_ent cmd = { .opcode = inv_info->opcode }; > > + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > > + struct arm_smmu_device *smmu = smmu_domain->smmu; > > + size_t granule_size = inv_info->granule_size; > > + unsigned long iova = 0; > > + size_t size = 0; > > + int ssid = 0; > > + > > + if (!smmu || !smmu_domain->s2 || domain->type != IOMMU_DOMAIN_NESTED) > > + return; > > + > > + switch (inv_info->opcode) { > > + case CMDQ_OP_CFGI_CD: > > + case CMDQ_OP_CFGI_CD_ALL: > > + return arm_smmu_sync_cd(smmu_domain, inv_info->ssid, true); > > Since we let the guest choose its own S1Fmt (and S1CDMax, yet not > S1DSS?), how can we assume leaf = true here? The s1dss is forwarded in the user_data structure too. So, the driver should have set that too down to a nested STE. Will add this missing pathway. And you are right that the guest OS can use a 2-level table, so we should set leaf = false to cover all cases, I think. > > + case CMDQ_OP_TLBI_NH_VA: > > + cmd.tlbi.asid = inv_info->asid; > > + fallthrough; > > + case CMDQ_OP_TLBI_NH_VAA: > > + if (!granule_size || !(granule_size & smmu->pgsize_bitmap) || > > Non-range invalidations with TG=0 are perfectly legal, and should not be > ignored. I assume that you are talking about the pgsize_bitmap check. QEMU embeds a !tg case into the granule_size [1]. So it might not be straightforward to cover that case. Let me see how to untangle different cases and handle them accordingly. [1] https://patchew.org/QEMU/20200824094811.15439-1-peter.maydell@linaro.org/20200824094811.15439-9-peter.maydell@linaro.org/ > > + granule_size & ~(1ULL << __ffs(granule_size))) > > If that's intended to mean is_power_of_2(), please just use is_power_of_2(). > > > + return; > > + > > + iova = inv_info->range.start; > > + size = inv_info->range.last - inv_info->range.start + 1; > > If the design here is that user_data is so deeply driver-specific and > special to the point that it can't possibly be passed as a type-checked > union of the known and publicly-visible UAPI types that it is, wouldn't > it make sense to just encode the whole thing in the expected format and > not have to make these kinds of niggling little conversions at both ends? Hmm, that makes sense to me. I just tracked back the history of Eric's previous work. There was a mismatch between guest and host that RIL isn't supported by the hardware. Now, guest can have whatever information it'd need from the host to send supported instructions. > > + if (!size) > > + return; > > + > > + cmd.tlbi.vmid = smmu_domain->s2->s2_cfg.vmid; > > + cmd.tlbi.leaf = inv_info->flags & IOMMU_SMMUV3_CMDQ_TLBI_VA_LEAF; > > + __arm_smmu_tlb_inv_range(&cmd, iova, size, granule_size, smmu_domain); > > + break; > > + case CMDQ_OP_TLBI_NH_ASID: > > + cmd.tlbi.asid = inv_info->asid; > > + fallthrough; > > + case CMDQ_OP_TLBI_NH_ALL: > > + cmd.tlbi.vmid = smmu_domain->s2->s2_cfg.vmid; > > + arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd); > > + break; > > + case CMDQ_OP_ATC_INV: > > + ssid = inv_info->ssid; > > + iova = inv_info->range.start; > > + size = inv_info->range.last - inv_info->range.start + 1; > > + break; > > Can we do any better than multiplying every single ATC_INV command, even > for random bogus StreamIDs, into multiple commands across every physical > device? In fact, I'm not entirely confident this isn't problematic, if > the guest wishes to send invalidations for one device specifically while > it's put some other device into a state where sending it a command would > do something bad. At the very least, it's liable to be confusing if the > guest sends a command for one StreamID but gets an error back for a > different one. We'd need here an sid translation from the guest value to the host value to specify a device, so as not to multiply the cmd with the device list, if I understand it correctly? > And if we expect ATS, what about PRI? Per patch #4 you're currently > offering that to the guest as well. Oh, I should have probably blocked PRI. The PRI and the fault injection will be followed after the basic 2-stage translation patches. And I don't have a supporting hardware to test PRI. > > > + default: > > + return; > > What about NSNH_ALL? That still needs to invalidate all the S1 context > that the guest *thinks* it's invalidating. NSNH_ALL is translated to NH_ALL at the guest level. But maybe it should have been done here instead. Thanks Nic
WARNING: multiple messages have this Message-ID (diff)
From: Nicolin Chen <nicolinc@nvidia.com> To: Robin Murphy <robin.murphy@arm.com> Cc: <jgg@nvidia.com>, <will@kernel.org>, <eric.auger@redhat.com>, <kevin.tian@intel.com>, <baolu.lu@linux.intel.com>, <joro@8bytes.org>, <shameerali.kolothum.thodi@huawei.com>, <jean-philippe@linaro.org>, <linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user Date: Thu, 9 Mar 2023 19:51:21 -0800 [thread overview] Message-ID: <ZAqpOQ+DDvEfq0Dg@Asurada-Nvidia> (raw) In-Reply-To: <1467e666-1b6c-c285-3f79-f8e8b088718b@arm.com> On Thu, Mar 09, 2023 at 02:49:14PM +0000, Robin Murphy wrote: > External email: Use caution opening links or attachments > > > On 2023-03-09 10:53, Nicolin Chen wrote: > > Add arm_smmu_cache_invalidate_user() function for user space to invalidate > > TLB entries and Context Descriptors, since either an IO page table entrie > > or a Context Descriptor in the user space is still cached by the hardware. > > > > The input user_data is defined in "struct iommu_hwpt_invalidate_arm_smmuv3" > > that contains the essential data for corresponding invalidation commands. > > > > Co-developed-by: Eric Auger <eric.auger@redhat.com> > > Signed-off-by: Eric Auger <eric.auger@redhat.com> > > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > > --- > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 56 +++++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > > > 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 ac63185ae268..7d73eab5e7f4 100644 > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > @@ -2880,9 +2880,65 @@ static void arm_smmu_remove_dev_pasid(struct device *dev, ioasid_t pasid) > > arm_smmu_sva_remove_dev_pasid(domain, dev, pasid); > > } > > > > +static void arm_smmu_cache_invalidate_user(struct iommu_domain *domain, > > + void *user_data) > > +{ > > + struct iommu_hwpt_invalidate_arm_smmuv3 *inv_info = user_data; > > + struct arm_smmu_cmdq_ent cmd = { .opcode = inv_info->opcode }; > > + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > > + struct arm_smmu_device *smmu = smmu_domain->smmu; > > + size_t granule_size = inv_info->granule_size; > > + unsigned long iova = 0; > > + size_t size = 0; > > + int ssid = 0; > > + > > + if (!smmu || !smmu_domain->s2 || domain->type != IOMMU_DOMAIN_NESTED) > > + return; > > + > > + switch (inv_info->opcode) { > > + case CMDQ_OP_CFGI_CD: > > + case CMDQ_OP_CFGI_CD_ALL: > > + return arm_smmu_sync_cd(smmu_domain, inv_info->ssid, true); > > Since we let the guest choose its own S1Fmt (and S1CDMax, yet not > S1DSS?), how can we assume leaf = true here? The s1dss is forwarded in the user_data structure too. So, the driver should have set that too down to a nested STE. Will add this missing pathway. And you are right that the guest OS can use a 2-level table, so we should set leaf = false to cover all cases, I think. > > + case CMDQ_OP_TLBI_NH_VA: > > + cmd.tlbi.asid = inv_info->asid; > > + fallthrough; > > + case CMDQ_OP_TLBI_NH_VAA: > > + if (!granule_size || !(granule_size & smmu->pgsize_bitmap) || > > Non-range invalidations with TG=0 are perfectly legal, and should not be > ignored. I assume that you are talking about the pgsize_bitmap check. QEMU embeds a !tg case into the granule_size [1]. So it might not be straightforward to cover that case. Let me see how to untangle different cases and handle them accordingly. [1] https://patchew.org/QEMU/20200824094811.15439-1-peter.maydell@linaro.org/20200824094811.15439-9-peter.maydell@linaro.org/ > > + granule_size & ~(1ULL << __ffs(granule_size))) > > If that's intended to mean is_power_of_2(), please just use is_power_of_2(). > > > + return; > > + > > + iova = inv_info->range.start; > > + size = inv_info->range.last - inv_info->range.start + 1; > > If the design here is that user_data is so deeply driver-specific and > special to the point that it can't possibly be passed as a type-checked > union of the known and publicly-visible UAPI types that it is, wouldn't > it make sense to just encode the whole thing in the expected format and > not have to make these kinds of niggling little conversions at both ends? Hmm, that makes sense to me. I just tracked back the history of Eric's previous work. There was a mismatch between guest and host that RIL isn't supported by the hardware. Now, guest can have whatever information it'd need from the host to send supported instructions. > > + if (!size) > > + return; > > + > > + cmd.tlbi.vmid = smmu_domain->s2->s2_cfg.vmid; > > + cmd.tlbi.leaf = inv_info->flags & IOMMU_SMMUV3_CMDQ_TLBI_VA_LEAF; > > + __arm_smmu_tlb_inv_range(&cmd, iova, size, granule_size, smmu_domain); > > + break; > > + case CMDQ_OP_TLBI_NH_ASID: > > + cmd.tlbi.asid = inv_info->asid; > > + fallthrough; > > + case CMDQ_OP_TLBI_NH_ALL: > > + cmd.tlbi.vmid = smmu_domain->s2->s2_cfg.vmid; > > + arm_smmu_cmdq_issue_cmd_with_sync(smmu, &cmd); > > + break; > > + case CMDQ_OP_ATC_INV: > > + ssid = inv_info->ssid; > > + iova = inv_info->range.start; > > + size = inv_info->range.last - inv_info->range.start + 1; > > + break; > > Can we do any better than multiplying every single ATC_INV command, even > for random bogus StreamIDs, into multiple commands across every physical > device? In fact, I'm not entirely confident this isn't problematic, if > the guest wishes to send invalidations for one device specifically while > it's put some other device into a state where sending it a command would > do something bad. At the very least, it's liable to be confusing if the > guest sends a command for one StreamID but gets an error back for a > different one. We'd need here an sid translation from the guest value to the host value to specify a device, so as not to multiply the cmd with the device list, if I understand it correctly? > And if we expect ATS, what about PRI? Per patch #4 you're currently > offering that to the guest as well. Oh, I should have probably blocked PRI. The PRI and the fault injection will be followed after the basic 2-stage translation patches. And I don't have a supporting hardware to test PRI. > > > + default: > > + return; > > What about NSNH_ALL? That still needs to invalidate all the S1 context > that the guest *thinks* it's invalidating. NSNH_ALL is translated to NH_ALL at the guest level. But maybe it should have been done here instead. Thanks Nic _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-10 3:52 UTC|newest] Thread overview: 330+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-09 10:53 [PATCH v1 00/14] Add Nested Translation Support for SMMUv3 Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 01/14] iommu: Add iommu_get_unmanaged_domain helper Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 12:51 ` Robin Murphy 2023-03-09 12:51 ` Robin Murphy 2023-03-09 14:19 ` Jason Gunthorpe 2023-03-09 14:19 ` Jason Gunthorpe 2023-03-09 19:04 ` Robin Murphy 2023-03-09 19:04 ` Robin Murphy 2023-03-10 0:23 ` Jason Gunthorpe 2023-03-10 0:23 ` Jason Gunthorpe 2023-03-10 8:41 ` Eric Auger 2023-03-10 8:41 ` Eric Auger 2023-03-10 15:55 ` Jason Gunthorpe 2023-03-10 15:55 ` Jason Gunthorpe 2023-03-16 1:21 ` Nicolin Chen 2023-03-16 1:21 ` Nicolin Chen 2023-03-16 18:42 ` Robin Murphy 2023-03-16 18:42 ` Robin Murphy 2023-03-16 20:01 ` Nicolin Chen 2023-03-16 20:01 ` Nicolin Chen 2023-03-20 12:51 ` Jason Gunthorpe 2023-03-20 12:51 ` Jason Gunthorpe 2023-03-10 10:14 ` Eric Auger 2023-03-10 10:14 ` Eric Auger 2023-03-10 15:33 ` Jason Gunthorpe 2023-03-10 15:33 ` Jason Gunthorpe 2023-03-10 15:44 ` Shameerali Kolothum Thodi 2023-03-10 15:44 ` Shameerali Kolothum Thodi 2023-03-10 15:56 ` Jason Gunthorpe 2023-03-10 15:56 ` Jason Gunthorpe 2023-03-10 16:07 ` Shameerali Kolothum Thodi 2023-03-10 16:07 ` Shameerali Kolothum Thodi 2023-03-10 16:21 ` Jason Gunthorpe 2023-03-10 16:21 ` Jason Gunthorpe 2023-03-10 16:30 ` Shameerali Kolothum Thodi 2023-03-10 16:30 ` Shameerali Kolothum Thodi 2023-03-10 17:03 ` Jason Gunthorpe 2023-03-10 17:03 ` Jason Gunthorpe 2023-03-22 16:07 ` Eric Auger 2023-03-22 16:07 ` Eric Auger 2023-03-22 17:02 ` Jason Gunthorpe 2023-03-22 17:02 ` Jason Gunthorpe 2023-03-22 17:41 ` Eric Auger 2023-03-22 17:41 ` Eric Auger 2023-03-22 18:07 ` Jason Gunthorpe 2023-03-22 18:07 ` Jason Gunthorpe 2023-03-16 19:51 ` Nicolin Chen 2023-03-16 19:51 ` Nicolin Chen 2023-03-16 19:56 ` Shameerali Kolothum Thodi 2023-03-16 19:56 ` Shameerali Kolothum Thodi 2023-03-22 15:44 ` Eric Auger 2023-03-22 15:44 ` Eric Auger 2023-03-09 10:53 ` [PATCH v1 02/14] iommufd: Add nesting related data structures for ARM SMMUv3 Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 13:42 ` Jean-Philippe Brucker 2023-03-09 13:42 ` Jean-Philippe Brucker 2023-03-09 14:48 ` Jason Gunthorpe 2023-03-09 14:48 ` Jason Gunthorpe 2023-03-09 18:26 ` Jean-Philippe Brucker 2023-03-09 18:26 ` Jean-Philippe Brucker 2023-03-09 21:01 ` Jason Gunthorpe 2023-03-09 21:01 ` Jason Gunthorpe 2023-03-10 12:16 ` Jean-Philippe Brucker 2023-03-10 12:16 ` Jean-Philippe Brucker 2023-03-10 14:52 ` Robin Murphy 2023-03-10 14:52 ` Robin Murphy 2023-03-10 15:25 ` Jason Gunthorpe 2023-03-10 15:25 ` Jason Gunthorpe 2023-03-10 15:57 ` Robin Murphy 2023-03-10 15:57 ` Robin Murphy 2023-03-10 16:03 ` Jason Gunthorpe 2023-03-10 16:03 ` Jason Gunthorpe 2023-03-17 10:10 ` Tian, Kevin 2023-03-17 10:10 ` Tian, Kevin 2023-03-17 10:04 ` Tian, Kevin 2023-03-17 10:04 ` Tian, Kevin 2023-03-10 4:50 ` Nicolin Chen 2023-03-10 4:50 ` Nicolin Chen 2023-03-10 12:54 ` Jean-Philippe Brucker 2023-03-10 12:54 ` Jean-Philippe Brucker 2023-03-10 14:00 ` Jason Gunthorpe 2023-03-10 14:00 ` Jason Gunthorpe 2023-03-10 16:06 ` Jason Gunthorpe 2023-03-10 16:06 ` Jason Gunthorpe 2023-03-16 0:59 ` Nicolin Chen 2023-03-16 0:59 ` Nicolin Chen 2023-03-09 15:26 ` Shameerali Kolothum Thodi 2023-03-09 15:26 ` Shameerali Kolothum Thodi 2023-03-09 15:40 ` Jason Gunthorpe 2023-03-09 15:40 ` Jason Gunthorpe 2023-03-09 15:51 ` Shameerali Kolothum Thodi 2023-03-09 15:51 ` Shameerali Kolothum Thodi 2023-03-09 15:59 ` Jason Gunthorpe 2023-03-09 15:59 ` Jason Gunthorpe 2023-03-09 16:07 ` Shameerali Kolothum Thodi 2023-03-09 16:07 ` Shameerali Kolothum Thodi 2023-03-10 5:26 ` Nicolin Chen 2023-03-10 5:26 ` Nicolin Chen 2023-03-10 5:36 ` Nicolin Chen 2023-03-10 5:36 ` Nicolin Chen 2023-03-10 12:55 ` Jason Gunthorpe 2023-03-10 12:55 ` Jason Gunthorpe 2023-03-10 5:18 ` Nicolin Chen 2023-03-10 5:18 ` Nicolin Chen 2023-03-10 5:04 ` Nicolin Chen 2023-03-10 5:04 ` Nicolin Chen 2023-03-10 11:33 ` Eric Auger 2023-03-10 11:33 ` Eric Auger 2023-03-10 12:51 ` Jason Gunthorpe 2023-03-10 12:51 ` Jason Gunthorpe 2023-03-17 10:17 ` Tian, Kevin 2023-03-17 10:17 ` Tian, Kevin 2023-03-09 10:53 ` [PATCH v1 03/14] iommufd/device: Setup MSI on kernel-managed domains Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-10 16:45 ` Eric Auger 2023-03-10 16:45 ` Eric Auger 2023-03-11 0:17 ` Nicolin Chen 2023-03-11 0:17 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 04/14] iommu/arm-smmu-v3: Add arm_smmu_hw_info Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 13:03 ` Robin Murphy 2023-03-09 13:03 ` Robin Murphy 2023-03-10 1:17 ` Nicolin Chen 2023-03-10 1:17 ` Nicolin Chen 2023-03-10 15:28 ` Robin Murphy 2023-03-10 15:28 ` Robin Murphy 2023-03-16 0:13 ` Nicolin Chen 2023-03-16 0:13 ` Nicolin Chen 2023-03-16 15:19 ` Robin Murphy 2023-03-16 15:19 ` Robin Murphy 2023-03-16 20:06 ` Nicolin Chen 2023-03-16 20:06 ` Nicolin Chen 2023-04-12 7:47 ` Nicolin Chen 2023-04-12 7:47 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 05/14] iommu/arm-smmu-v3: Remove ARM_SMMU_DOMAIN_NESTED Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-10 16:39 ` Eric Auger 2023-03-10 16:39 ` Eric Auger 2023-03-10 17:05 ` Jason Gunthorpe 2023-03-10 17:05 ` Jason Gunthorpe 2023-03-11 0:24 ` Nicolin Chen 2023-03-11 0:24 ` Nicolin Chen 2023-03-11 0:23 ` Nicolin Chen 2023-03-11 0:23 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 06/14] iommu/arm-smmu-v3: Unset corresponding STE fields when s2_cfg is NULL Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 13:13 ` Robin Murphy 2023-03-09 13:13 ` Robin Murphy 2023-03-09 18:24 ` Shameerali Kolothum Thodi 2023-03-09 18:24 ` Shameerali Kolothum Thodi 2023-03-10 1:54 ` Nicolin Chen 2023-03-10 1:54 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 07/14] iommu/arm-smmu-v3: Add STRTAB_STE_0_CFG_NESTED for 2-stage translation Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 08/14] iommu/arm-smmu-v3: Prepare for nested domain support Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-10 20:39 ` Robin Murphy 2023-03-10 20:39 ` Robin Murphy 2023-03-11 12:40 ` Nicolin Chen 2023-03-11 12:40 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 09/14] iommu/arm-smmu-v3: Implement arm_smmu_get_unmanaged_domain Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 10/14] iommu/arm-smmu-v3: Pass in user_cfg to arm_smmu_domain_finalise Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 11/14] iommu/arm-smmu-v3: Add arm_smmu_domain_alloc_user Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-24 15:28 ` Eric Auger 2023-03-24 15:28 ` Eric Auger 2023-03-24 17:40 ` Nicolin Chen 2023-03-24 17:40 ` Nicolin Chen 2023-03-24 17:50 ` Jason Gunthorpe 2023-03-24 17:50 ` Jason Gunthorpe 2023-03-24 18:00 ` Nicolin Chen 2023-03-24 18:00 ` Nicolin Chen 2023-03-24 15:33 ` Eric Auger 2023-03-24 15:33 ` Eric Auger 2023-03-24 17:43 ` Nicolin Chen 2023-03-24 17:43 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 12/14] iommu/arm-smmu-v3: Support IOMMU_DOMAIN_NESTED type of allocations Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 13:20 ` Robin Murphy 2023-03-09 13:20 ` Robin Murphy 2023-03-09 14:28 ` Robin Murphy 2023-03-09 14:28 ` Robin Murphy 2023-03-10 1:34 ` Nicolin Chen 2023-03-10 1:34 ` Nicolin Chen 2023-03-24 15:44 ` Eric Auger 2023-03-24 15:44 ` Eric Auger 2023-03-24 16:30 ` Jason Gunthorpe 2023-03-24 16:30 ` Jason Gunthorpe 2023-03-24 17:50 ` Nicolin Chen 2023-03-24 17:50 ` Nicolin Chen 2023-03-24 17:51 ` Jason Gunthorpe 2023-03-24 17:51 ` Jason Gunthorpe 2023-03-24 17:55 ` Nicolin Chen 2023-03-24 17:55 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 13/14] iommu/arm-smmu-v3: Add CMDQ_OP_TLBI_NH_VAA and CMDQ_OP_TLBI_NH_ALL Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 13:44 ` Robin Murphy 2023-03-09 13:44 ` Robin Murphy 2023-03-10 1:19 ` Nicolin Chen 2023-03-10 1:19 ` Nicolin Chen 2023-03-09 10:53 ` [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user Nicolin Chen 2023-03-09 10:53 ` Nicolin Chen 2023-03-09 14:49 ` Robin Murphy 2023-03-09 14:49 ` Robin Murphy 2023-03-09 15:31 ` Jason Gunthorpe 2023-03-09 15:31 ` Jason Gunthorpe 2023-03-10 4:20 ` Nicolin Chen 2023-03-10 4:20 ` Nicolin Chen 2023-03-10 16:19 ` Jason Gunthorpe 2023-03-10 16:19 ` Jason Gunthorpe 2023-03-11 11:56 ` Nicolin Chen 2023-03-11 11:56 ` Nicolin Chen 2023-03-11 12:53 ` Nicolin Chen 2023-03-11 12:53 ` Nicolin Chen 2023-03-20 13:03 ` Jason Gunthorpe 2023-03-20 13:03 ` Jason Gunthorpe 2023-03-20 15:56 ` Nicolin Chen 2023-03-20 15:56 ` Nicolin Chen 2023-03-20 16:04 ` Jason Gunthorpe 2023-03-20 16:04 ` Jason Gunthorpe 2023-03-20 16:59 ` Nicolin Chen 2023-03-20 16:59 ` Nicolin Chen 2023-03-20 18:45 ` Jason Gunthorpe 2023-03-20 18:45 ` Jason Gunthorpe 2023-03-20 21:22 ` Nicolin Chen 2023-03-20 21:22 ` Nicolin Chen 2023-03-20 22:19 ` Jason Gunthorpe 2023-03-20 22:19 ` Jason Gunthorpe 2023-03-22 20:57 ` Nicolin Chen 2023-03-22 20:57 ` Nicolin Chen 2023-03-23 12:17 ` Jason Gunthorpe 2023-03-23 12:17 ` Jason Gunthorpe 2023-03-17 9:41 ` Tian, Kevin 2023-03-17 9:41 ` Tian, Kevin 2023-03-17 14:24 ` Nicolin Chen 2023-03-17 14:24 ` Nicolin Chen 2023-03-20 12:59 ` Jason Gunthorpe 2023-03-20 12:59 ` Jason Gunthorpe 2023-03-20 16:12 ` Nicolin Chen 2023-03-20 16:12 ` Nicolin Chen 2023-03-20 18:00 ` Jason Gunthorpe 2023-03-20 18:00 ` Jason Gunthorpe 2023-03-21 8:34 ` Tian, Kevin 2023-03-21 8:34 ` Tian, Kevin 2023-03-21 11:48 ` Jason Gunthorpe 2023-03-21 11:48 ` Jason Gunthorpe 2023-03-22 6:42 ` Nicolin Chen 2023-03-22 6:42 ` Nicolin Chen 2023-03-22 12:43 ` Jason Gunthorpe 2023-03-22 12:43 ` Jason Gunthorpe 2023-03-22 17:11 ` Nicolin Chen 2023-03-22 17:11 ` Nicolin Chen 2023-03-22 17:28 ` Jason Gunthorpe 2023-03-22 17:28 ` Jason Gunthorpe 2023-03-22 19:21 ` Nicolin Chen 2023-03-22 19:21 ` Nicolin Chen 2023-03-22 19:41 ` Jason Gunthorpe 2023-03-22 19:41 ` Jason Gunthorpe 2023-03-22 20:43 ` Nicolin Chen 2023-03-22 20:43 ` Nicolin Chen 2023-03-23 12:16 ` Jason Gunthorpe 2023-03-23 12:16 ` Jason Gunthorpe 2023-03-23 18:13 ` Nicolin Chen 2023-03-23 18:13 ` Nicolin Chen 2023-03-23 18:27 ` Jason Gunthorpe 2023-03-23 18:27 ` Jason Gunthorpe 2023-03-24 9:02 ` Tian, Kevin 2023-03-24 9:02 ` Tian, Kevin 2023-03-24 14:57 ` Jason Gunthorpe 2023-03-24 14:57 ` Jason Gunthorpe 2023-03-24 17:35 ` Nicolin Chen 2023-03-24 17:35 ` Nicolin Chen 2023-03-28 3:03 ` Tian, Kevin 2023-03-28 3:03 ` Tian, Kevin 2023-03-24 8:47 ` Tian, Kevin 2023-03-24 8:47 ` Tian, Kevin 2023-03-24 14:44 ` Jason Gunthorpe 2023-03-24 14:44 ` Jason Gunthorpe 2023-03-28 2:48 ` Tian, Kevin 2023-03-28 2:48 ` Tian, Kevin 2023-03-28 12:26 ` Jason Gunthorpe 2023-03-28 12:26 ` Jason Gunthorpe 2023-03-31 8:09 ` Tian, Kevin 2023-03-31 8:09 ` Tian, Kevin 2023-03-17 9:24 ` Tian, Kevin 2023-03-17 9:24 ` Tian, Kevin 2023-03-10 3:51 ` Nicolin Chen [this message] 2023-03-10 3:51 ` Nicolin Chen 2023-03-10 17:53 ` Robin Murphy 2023-03-10 17:53 ` Robin Murphy 2023-03-10 18:49 ` Jason Gunthorpe 2023-03-10 18:49 ` Jason Gunthorpe 2023-03-11 12:38 ` Nicolin Chen 2023-03-11 12:38 ` Nicolin Chen 2023-03-13 13:07 ` Robin Murphy 2023-03-13 13:07 ` Robin Murphy 2023-03-16 0:01 ` Nicolin Chen 2023-03-16 0:01 ` Nicolin Chen 2023-03-16 14:58 ` Robin Murphy 2023-03-16 14:58 ` Robin Murphy 2023-03-16 21:09 ` Nicolin Chen 2023-03-16 21:09 ` Nicolin Chen 2023-03-20 1:32 ` Nicolin Chen 2023-03-20 1:32 ` Nicolin Chen 2023-03-20 13:11 ` Jason Gunthorpe 2023-03-20 13:11 ` Jason Gunthorpe 2023-03-20 15:28 ` Nicolin Chen 2023-03-20 15:28 ` Nicolin Chen 2023-03-20 16:01 ` Jason Gunthorpe 2023-03-20 16:01 ` Jason Gunthorpe 2023-03-20 16:35 ` Nicolin Chen 2023-03-20 16:35 ` Nicolin Chen 2023-03-20 18:07 ` Jason Gunthorpe 2023-03-20 18:07 ` Jason Gunthorpe 2023-03-20 20:46 ` Nicolin Chen 2023-03-20 20:46 ` Nicolin Chen 2023-03-20 22:14 ` Jason Gunthorpe 2023-03-20 22:14 ` Jason Gunthorpe 2023-03-22 5:14 ` Nicolin Chen 2023-03-22 5:14 ` Nicolin Chen 2023-03-24 8:55 ` Tian, Kevin 2023-03-24 8:55 ` Tian, Kevin 2023-03-17 9:47 ` Tian, Kevin 2023-03-17 9:47 ` Tian, Kevin 2023-03-17 14:16 ` Nicolin Chen 2023-03-17 14:16 ` Nicolin Chen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZAqpOQ+DDvEfq0Dg@Asurada-Nvidia \ --to=nicolinc@nvidia.com \ --cc=baolu.lu@linux.intel.com \ --cc=eric.auger@redhat.com \ --cc=iommu@lists.linux.dev \ --cc=jean-philippe@linaro.org \ --cc=jgg@nvidia.com \ --cc=joro@8bytes.org \ --cc=kevin.tian@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robin.murphy@arm.com \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.