From mboxrd@z Thu Jan  1 00:00:00 1970
From: will.deacon@arm.com (Will Deacon)
Date: Thu, 7 Apr 2016 15:46:02 +0100
Subject: [PATCH] iommu/arm-smmu: Fix stream-match conflict with
 IOMMU_DOMAIN_DMA
In-Reply-To: <5702368D.6060706@linaro.org>
References: <1459527597-10740-1-git-send-email-will.deacon@arm.com>
 <5702368D.6060706@linaro.org>
Message-ID: <20160407144601.GJ5657@arm.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Hi Eric,

On Mon, Apr 04, 2016 at 11:40:29AM +0200, Eric Auger wrote:
> On 04/01/2016 06:19 PM, Will Deacon wrote:
> > Commit cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass
> > for now") ignores requests to attach a device to the default domain
> > since, without IOMMU-basked DMA ops available everywhere, the default
> > domain will just lead to unexpected transaction faults being reported.
> > 
> > Unfortunately, the way this was implemented on SMMUv2 causes a
> > regression with VFIO PCI device passthrough under KVM on AMD Seattle.
> > On this system, the host controller device is associated with both a
> > pci_dev *and* a platform_device, and can therefore end up with duplicate
> > SMR entries, resulting in a stream-match conflict at runtime.
> > 
> > This patch amends the original fix so that attaching to IOMMU_DOMAIN_DMA
> > is rejected even before configuring the SMRs. This restores the old
> > behaviour for now, but we'll need to look at handing host controllers
> > specially when we come to supporting the default domain fully.
> 
> This works fine for me, before and after PCIe assignment. However before
> giving my T-b I would like to investigate another regression I observe
> wrt SRIOV assignment. Assigning the 1st VF works fine. However assigning
> a second VF does not work anymore (it used to in the past). I get
> -ENOSPC from arm_smmu_master_configure_smrs

Did you get anywhere debugging this?

Will