Re: [PATCH v2] iommu/vt-d: Fix broken device issue when using iommu=pt

[Yijing Wang <wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>]

On 2014/8/25 20:11, Sathya Perla wrote:
>> -----Original Message-----
>> From: Yijing Wang [mailto:wangyijing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org]
>>
>> On 2014/8/25 17:32, Sathya Perla wrote:
>>>> -----Original Message-----
>>>> From: Joerg Roedel [mailto:joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org]
>>>>
>>>> [Adding the Emulex driver developers to Cc for some input on the device,
>>>>  and why it might use wrong request ids]
>>>>
>>>> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
>>>>> We found some strange devices in HP C7000 and Huawei Storage Server.
>>>> These
>>>>> devices can not be enumerated by OS, but they still did DMA read/write
>>>>> without OS management. Because iommu will not create the DMA
>>>> mapping for
>>>>> these devices, the DMA read/write will be blocked by iommu hardware.
> ...
>>>>> Eg.
>>>>> in HP C7000:
>>>>>  \-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
>>>>>              +-01.0-[11]--
>>>>> 			 +-01.1-[02]--
>>>>> 			 +-02.0-[04]--+-00.0  Emulex Corporation OneConnect
>>>> 10Gb NIC (be3)
>>>>> 	         |            +-00.1  Emulex Corporation OneConnect 10Gb NIC (be3)
>>>>> 	         |            +-00.2  Emulex Corporation OneConnect 10Gb iSCSI
>>>> Initiator (be3)
>>>>> 	         |            \-00.3  Emulex Corporation OneConnect 10Gb iSCSI
>>>> Initiator (be3)
>>>>> 	         +-02.1-[12]--
>>>>> Kernel only found four devices in bus 0x04, but we found following DMA
>>>> errors in dmesg.
>>>>>
>>>>> [ 1438.477262] DRHD: handling fault status reg 402
>>>>> [ 1438.498278] DMAR:[DMA Write] Request device [04:00.4] fault addr
>>>> bdf70000
>>>>> [ 1438.498280] DMAR:[fault reason 02] Present bit in context entry is
>> clear
>>>>> [ 1438.566458] DMAR:[DMA Write] Request device [04:00.5] fault addr
>>>> bdf70000
>>>>> [ 1438.566460] DMAR:[fault reason 02] Present bit in context entry is
>> clear
>>>>> [ 1438.635211] DMAR:[DMA Write] Request device [04:00.6] fault addr
>>>> bdf70000
>>>>> [ 1438.635213] DMAR:[fault reason 02] Present bit in context entry is
>> clear
>>>>> [ 1438.703849] DMAR:[DMA Write] Request device [04:00.7] fault addr
>>>> bdf70000
>>>>> [ 1438.703851] DMAR:[fault reason 02] Present bit in context entry is
>> clear
> 
> Hi Wang, from the kernel log I can see that the faulting address 0xbdf70000 falls in the
> RMRR range the BIOS requested:
> [    0.111343] DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff
> 
> An identity map is being setup for the visible functions, but not for the "invisible"
> functions:
> [    2.695951] IOMMU: Setting identity map for device 0000:04:00.0 [0xbdf6e000 - 0xbdf6efff]
> [    2.698637] IOMMU: Setting identity map for device 0000:04:00.1 [0xbdf6e000 - 0xbdf6efff]
> [    2.702551] IOMMU: Setting identity map for device 0000:04:00.2 [0xbdf6e000 - 0xbdf6efff]
> [    2.705134] IOMMU: Setting identity map for device 0000:04:00.3 [0xbdf6e000 - 0xbdf6efff]
> 
> I'm going to follow-up with our FW folks as to why functions 04.00.4-7 are invisible
> but yet are trying to access the RMRR memory region.
> 
> Could you also please send the me the FW version (output of "ethtool -i eth0")

Hi Sathya, thanks for your help. FW version is 4.6.247.5   driver version is 4.4.161.0s

Thanks!
Yijing.

> 
> thanks,
> -Sathya
> 
> .
> 


-- 
Thanks!
Yijing