| Message ID | 1500456838-18405-2-git-send-email-anup.patel@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 19/07/17 10:33, Anup Patel wrote: > Some of the IOMMUs (such as ARM SMMU) are capable of bypassing > transactions for which no IOMMU domain is configured. > > This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU > drivers to advertise transation bypass capability of an IOMMU. Whatever the intended semantics of this are, I can't help thinking it would be better served by allowing callers to explicitly allocate their own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the problem we have with legacy virtio devices behind real IOMMUs. Robin. > Signed-off-by: Anup Patel <anup.patel@broadcom.com> > --- > include/linux/iommu.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 2cb54ad..6bbb4cc 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -101,6 +101,10 @@ enum iommu_cap { > transactions */ > IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */ > IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */ > + IOMMU_CAP_BYPASS, /* > + * IOMMU can bypass transactions for > + * which domain is not configured > + */ > }; > > /* >
On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: > On 19/07/17 10:33, Anup Patel wrote: >> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing >> transactions for which no IOMMU domain is configured. >> >> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU >> drivers to advertise transation bypass capability of an IOMMU. > > Whatever the intended semantics of this are, I can't help thinking it > would be better served by allowing callers to explicitly allocate their > own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the > problem we have with legacy virtio devices behind real IOMMUs. We want to use VFIO no-IOMMU mode for FlexRM device but currently it does not allow on our SOC because IOMMU ops are registered for platform bus. Regards, Anup
On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote: > On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: > > On 19/07/17 10:33, Anup Patel wrote: > >> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing > >> transactions for which no IOMMU domain is configured. > >> > >> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU > >> drivers to advertise transation bypass capability of an IOMMU. > > > > Whatever the intended semantics of this are, I can't help thinking it > > would be better served by allowing callers to explicitly allocate their > > own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the > > problem we have with legacy virtio devices behind real IOMMUs. > > We want to use VFIO no-IOMMU mode for FlexRM device but > currently it does not allow on our SOC because IOMMU ops are > registered for platform bus. Why do you want to use no-IOMMU mode if you have an IOMMU, and why you do think the individual IOMMU drivers are the place to implement this? NAK to the SMMU patches, for the reasons outlined by Robin. Will
On Wed, Jul 19, 2017 at 4:53 PM, Will Deacon <will.deacon@arm.com> wrote: > On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote: >> On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: >> > On 19/07/17 10:33, Anup Patel wrote: >> >> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing >> >> transactions for which no IOMMU domain is configured. >> >> >> >> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU >> >> drivers to advertise transation bypass capability of an IOMMU. >> > >> > Whatever the intended semantics of this are, I can't help thinking it >> > would be better served by allowing callers to explicitly allocate their >> > own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the >> > problem we have with legacy virtio devices behind real IOMMUs. >> >> We want to use VFIO no-IOMMU mode for FlexRM device but >> currently it does not allow on our SOC because IOMMU ops are >> registered for platform bus. > > Why do you want to use no-IOMMU mode if you have an IOMMU, and why you do > think the individual IOMMU drivers are the place to implement this? > > NAK to the SMMU patches, for the reasons outlined by Robin. We have limited number of SMRs on our SOC. There are lot of devices for which we can potentially configure SMMU but then due to limited number of SMRs so we use SMMU only for certain devices. For FlexRM device on our SOC, we don't intend to use SMMU hence we need VFIO no-IOMMU mode working for FlexRM device on our SOC. Please re-consider your NAK. Regards, Anup
On 19/07/17 12:26, Anup Patel wrote: > On Wed, Jul 19, 2017 at 4:53 PM, Will Deacon <will.deacon@arm.com> wrote: >> On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote: >>> On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: >>>> On 19/07/17 10:33, Anup Patel wrote: >>>>> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing >>>>> transactions for which no IOMMU domain is configured. >>>>> >>>>> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU >>>>> drivers to advertise transation bypass capability of an IOMMU. >>>> >>>> Whatever the intended semantics of this are, I can't help thinking it >>>> would be better served by allowing callers to explicitly allocate their >>>> own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the >>>> problem we have with legacy virtio devices behind real IOMMUs. >>> >>> We want to use VFIO no-IOMMU mode for FlexRM device but >>> currently it does not allow on our SOC because IOMMU ops are >>> registered for platform bus. >> >> Why do you want to use no-IOMMU mode if you have an IOMMU, and why you do >> think the individual IOMMU drivers are the place to implement this? >> >> NAK to the SMMU patches, for the reasons outlined by Robin. > > We have limited number of SMRs on our SOC. > > There are lot of devices for which we can potentially > configure SMMU but then due to limited number of > SMRs so we use SMMU only for certain devices. Is the stream ID allocation so whacked out that you can't use masking? Robin. > For FlexRM device on our SOC, we don't intend to > use SMMU hence we need VFIO no-IOMMU mode > working for FlexRM device on our SOC. > > Please re-consider your NAK. > > Regards, > Anup >
On Wed, Jul 19, 2017 at 04:56:38PM +0530, Anup Patel wrote: > On Wed, Jul 19, 2017 at 4:53 PM, Will Deacon <will.deacon@arm.com> wrote: > > On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote: > >> On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: > >> > On 19/07/17 10:33, Anup Patel wrote: > >> >> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing > >> >> transactions for which no IOMMU domain is configured. > >> >> > >> >> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU > >> >> drivers to advertise transation bypass capability of an IOMMU. > >> > > >> > Whatever the intended semantics of this are, I can't help thinking it > >> > would be better served by allowing callers to explicitly allocate their > >> > own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the > >> > problem we have with legacy virtio devices behind real IOMMUs. > >> > >> We want to use VFIO no-IOMMU mode for FlexRM device but > >> currently it does not allow on our SOC because IOMMU ops are > >> registered for platform bus. > > > > Why do you want to use no-IOMMU mode if you have an IOMMU, and why you do > > think the individual IOMMU drivers are the place to implement this? > > > > NAK to the SMMU patches, for the reasons outlined by Robin. > > We have limited number of SMRs on our SOC. > > There are lot of devices for which we can potentially > configure SMMU but then due to limited number of > SMRs so we use SMMU only for certain devices. > > For FlexRM device on our SOC, we don't intend to > use SMMU hence we need VFIO no-IOMMU mode > working for FlexRM device on our SOC. > > Please re-consider your NAK. I'm afraid it still stands for the current implementation. If you can't solve the SMR restriction by grouping things appropriately (which would be my strong preference), then I think you'll have to follow-up on Robin's suggestion of implementing support for IDENTITY domains in VFIO for no-IOMMU mode to be used even when an IOMMU is present. Will
On Wed, Jul 19, 2017 at 5:00 PM, Will Deacon <will.deacon@arm.com> wrote: > On Wed, Jul 19, 2017 at 04:56:38PM +0530, Anup Patel wrote: >> On Wed, Jul 19, 2017 at 4:53 PM, Will Deacon <will.deacon@arm.com> wrote: >> > On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote: >> >> On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy <robin.murphy@arm.com> wrote: >> >> > On 19/07/17 10:33, Anup Patel wrote: >> >> >> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing >> >> >> transactions for which no IOMMU domain is configured. >> >> >> >> >> >> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU >> >> >> drivers to advertise transation bypass capability of an IOMMU. >> >> > >> >> > Whatever the intended semantics of this are, I can't help thinking it >> >> > would be better served by allowing callers to explicitly allocate their >> >> > own IOMMU_DOMAIN_IDENTITY domains. That would also be useful for the >> >> > problem we have with legacy virtio devices behind real IOMMUs. >> >> >> >> We want to use VFIO no-IOMMU mode for FlexRM device but >> >> currently it does not allow on our SOC because IOMMU ops are >> >> registered for platform bus. >> > >> > Why do you want to use no-IOMMU mode if you have an IOMMU, and why you do >> > think the individual IOMMU drivers are the place to implement this? >> > >> > NAK to the SMMU patches, for the reasons outlined by Robin. >> >> We have limited number of SMRs on our SOC. >> >> There are lot of devices for which we can potentially >> configure SMMU but then due to limited number of >> SMRs so we use SMMU only for certain devices. >> >> For FlexRM device on our SOC, we don't intend to >> use SMMU hence we need VFIO no-IOMMU mode >> working for FlexRM device on our SOC. >> >> Please re-consider your NAK. > > I'm afraid it still stands for the current implementation. If you can't > solve the SMR restriction by grouping things appropriately (which would be > my strong preference), then I think you'll have to follow-up on Robin's > suggestion of implementing support for IDENTITY domains in VFIO for no-IOMMU > mode to be used even when an IOMMU is present. > Yes, we have considered making stream-id space for devices to be continuguous but this cannot be fixed in our current SOC. We will have to live with this limitation for our current SOC and it will be only fixed in future. Regards, Anup
diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 2cb54ad..6bbb4cc 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -101,6 +101,10 @@ enum iommu_cap { transactions */ IOMMU_CAP_INTR_REMAP, /* IOMMU supports interrupt isolation */ IOMMU_CAP_NOEXEC, /* IOMMU_NOEXEC flag */ + IOMMU_CAP_BYPASS, /* + * IOMMU can bypass transactions for + * which domain is not configured + */ }; /*
Some of the IOMMUs (such as ARM SMMU) are capable of bypassing transactions for which no IOMMU domain is configured. This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU drivers to advertise transation bypass capability of an IOMMU. Signed-off-by: Anup Patel <anup.patel@broadcom.com> --- include/linux/iommu.h | 4 ++++ 1 file changed, 4 insertions(+)