linux-kernel - Re: [PATCH 1/5] iommu: Add capability IOMMU_CAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170719113017.GH13642@arm.com>
Date:   Wed, 19 Jul 2017 12:30:17 +0100
From:   Will Deacon <will.deacon@....com>
To:     Anup Patel <anup.patel@...adcom.com>
Cc:     Robin Murphy <robin.murphy@....com>,
        Joerg Roedel <joro@...tes.org>,
        Baptiste Reynal <b.reynal@...tualopensystems.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Scott Branden <sbranden@...adcom.com>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux IOMMU <iommu@...ts.linux-foundation.org>,
        kvm@...r.kernel.org,
        BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>
Subject: Re: [PATCH 1/5] iommu: Add capability IOMMU_CAP_BYPASS

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@....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@....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