Re: [PATCH] iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMA

[Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

Hi Will,
On 04/07/2016 04:46 PM, Will Deacon wrote:
> 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?
Yes: http://www.spinics.net/lists/arm-kernel/msg495024.html

Eric
> 
> Will
>