Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

[Robin Murphy]

On 29/10/15 18:28, Will Deacon wrote:
> On Tue, Oct 27, 2015 at 10:00:11AM -0600, Alex Williamson wrote:
> > On Tue, 2015-10-27 at 15:40 +0000, Will Deacon wrote:
> > > On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote:
> > > > Would it be possible to add iommu_domain_geometry support to arm-smmu.c?
> > > > In addition to this test to verify that DMA cannot bypass the IOMMU, I'd
> > > > eventually like to pass the aperture information out through the VFIO
> > > > API.  Thanks,
> > >
> > > The slight snag here is that we don't know which SMMU in the system the
> > > domain is attached to at the point when the geometry is queried, so I
> > > can't give you an upper bound on the aperture. For example, if there is
> > > an SMMU with a 32-bit input address and another with a 48-bit input
> > > address.
> > >
> > > We could play the same horrible games that we do with the pgsize bitmap,
> > > and truncate some global aperture everytime we probe an SMMU device, but
> > > I'd really like to have fewer hacks like that if possible. The root of
> > > the problem is still that domains are allocated for a bus, rather than
> > > an IOMMU instance.
> >
> > Yes, Intel VT-d has this issue as well.  In theory we can have
> > heterogeneous IOMMU hardware units (DRHDs) in a system and the upper
> > bound of the geometry could be diminished if we add a less capable DRHD
> > into the domain.  I suspect this is more a theoretical problem than a
> > practical one though as we're typically mixing similar DRHDs and I think
> > we're still capable of 39-bit addressing in the least capable version
> > per the spec.
> >
> > In any case, I really want to start testing geometry.force_aperture,
> > even if we're not yet comfortable to expose the IOMMU limits to the
> > user.  The vfio type1 shouldn't be enabled at all for underlying
> > hardware that allows DMA bypass.  Thanks,
>
> Ok, I'll put it on my list of things to look at under the assumption that
> the actual aperture limits don't need to be accurate as long as DMA to
> an arbitrary unmapped address always faults.

I'm pretty sure we'd only ever set the aperture to the full input 
address range anyway (since we're not a GART-type thing), in which case 
we should only need to worry about unmatched streams that don't hit in a 
domain at all. Doesn't the disable_bypass option already cover that? 
(FWIW I hacked it up for v2 a while back, too[0]).

Robin.

[0]:http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=23a251189fa3330b799a837bd8eb1023aa2dcea4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/