Re: dmar pte read access not set error messages on hp dl388 gen8 systems

[Lu Baolu <baolu.lu@linux.intel.com>]

Hi,

On 12/10/19 2:16 PM, Jerry Snitselaar wrote:
> On Mon Dec 09 19, Jerry Snitselaar wrote:
>> On Mon Dec 09 19, Jerry Snitselaar wrote:
>>> On Mon Dec 09 19, Jerry Snitselaar wrote:
>>> [snip]
>>>>
>>>> A call to iommu_map is failing.
>>>>
>>>> [   36.686881] pci 0000:01:00.2: iommu_group_add_device: calling 
>>>> iommu_group_create_direct_mappings
>>>> [   36.689843] pci 0000:01:00.2: iommu_group_create_direct_mappings: 
>>>> iterating through mappings
>>>> [   36.692757] pci 0000:01:00.2: iommu_group_create_direct_mappings: 
>>>> calling apply_resv_region
>>>> [   36.695526] pci 0000:01:00.2: e_direct_mappings: entry type is 
>>>> direct
>>>> [   37.198053] iommu: iommu_map: ops->map failed iova 0xbddde000 pa 
>>>> 0x00000000bddde000 pgsize 0x1000
>>>> [   37.201357] pci 0000:01:00.2: iommu_group_create_direct_mappings: 
>>>> iommu_map failed
>>>> [   37.203973] pci 0000:01:00.2: iommu_group_create_direct_mappings: 
>>>> leaving func
>>>> [   37.206385] pci 0000:01:00.2: iommu_group_add_device: calling 
>>>> __iommu_attach_device
>>>> [   37.208950] pci 0000:01:00.2: Adding to iommu group 25
>>>> [   37.210660] pci 0000:01:00.2: DMAR: domain->type is dma
>>>>
>>>
>>> It bails at the dmar_domain->flags & DOMAIN_FLAG_LOSE_CHILDREN check
>>> at the beginning of intel_iommu_map.  I will verify, but it looks like
>>> that is getting set when intel_iommu_add_device is called for 01:00.1.
>>> request_default_domain_for_dev for 01:00.1 will return -EBUSY because
>>> iommu_group_device_count(group) != 1.
>>>
>>
>> Also I see 01:00.0 and others that are the first in a group exiting 
>> iommu_group_create_direct_mappings
>> at the (!domain || domain->type != IOMMU_DOMAIN_DMA) check. In 
>> request_default_domain_for_dev default_domain
>> doesn't getting set until after that call. Should the 
>> iommu_group_create_direct_mappings call be moved below
>> where group->default_domain gets set?
>>
> 
> Doing this the system boots, and I don't get any dmar pte read errors. I 
> still see the map failing because
> of the DOMAIN_FLAG_LOSE_CHILDREN in those cases mentioned above, but it 
> no longer is spitting out tons of
> dmar pte read errors.

You can post a patch if you think this is worth of.

Best regards,
baolu

> 
>>>> Also fails for 01:00.4:
>>>>
>>>> [   37.212448] pci 0000:01:00.4: iommu_group_add_device: calling 
>>>> iommu_group_create_direct_mappings
>>>> [   37.215382] pci 0000:01:00.4: iommu_group_create_direct_mappings: 
>>>> iterating through mappings
>>>> [   37.218170] pci 0000:01:00.4: iommu_group_create_direct_mappings: 
>>>> calling apply_resv_region
>>>> [   37.220933] pci 0000:01:00.4: iommu_group_create_direct_mappings: 
>>>> entry type is direct-relaxable
>>>> [   37.223932] iommu: iommu_map: ops->map failed iova 0xbddde000 pa 
>>>> 0x00000000bddde000 pgsize 0x1000
>>>> [   37.226857] pci 0000:01:00.4: iommu_group_create_direct_mappings: 
>>>> iommu_map failed
>>>> [   37.229300] pci 0000:01:00.4: iommu_group_create_direct_mappings: 
>>>> leaving func
>>>> [   37.231648] pci 0000:01:00.4: iommu_group_add_device: calling 
>>>> __iommu_attach_device
>>>> [   37.234194] pci 0000:01:00.4: Adding to iommu group 25
>>>> [   37.236192] pci 0000:01:00.4: DMAR: domain->type is dma
>>>> [   37.237958] pci 0000:01:00.4: DMAR: device default domain type is 
>>>> identity. requesting identity domain
>>>> [   37.241061] pci 0000:01:00.4: don't change mappings of existing 
>>>> d37.489870] pci 0000:01:00.4: DMAR: Device uses a private identity 
>>>> domain.
>>>>
>>>> There is an RMRR for 0xbddde000-0xddddefff:
>>>>
>>>> [63Ah 1594   2]                Subtable Type : 0001 [Reserved Memory 
>>>> Region]
>>>> [63Ch 1596   2]                       Length : 0036
>>>>
>>>> [63Eh 1598   2]                     Reserved : 0000
>>>> [640h 1600   2]           PCI Segment Number : 0000
>>>> [642h 1602   8]                 Base Address : 00000000BDDDE000
>>>> [64Ah 1610   8]          End Address (limit) : 00000000BDDDEFFF
>>>>
>>>> [652h 1618   1]            Device Scope Type : 01 [PCI Endpoint Device]
>>>> [653h 1619   1]                 Entry Length : 0A
>>>> [654h 1620   2]                     Reserved : 0000
>>>> [656h 1622   1]               Enumeration ID : 00
>>>> [657h 1623   1]               PCI Bus Number : 00
>>>>
>>>> [658h 1624   2]                     PCI Path : 1C,07
>>>>
>>>> [65Ah 1626   2]                     PCI Path : 00,00
>>>>
>>>>
>>>> [65Ch 1628   1]            Device Scope Type : 01 [PCI Endpoint Device]
>>>> [65Dh 1629   1]                 Entry Length : 0A
>>>> [65Eh 1630   2]                     Reserved : 0000
>>>> [660h 1632   1]               Enumeration ID : 00
>>>> [661h 1633   1]               PCI Bus Number : 00
>>>>
>>>> [662h 1634   2]                     PCI Path : 1C,07
>>>>
>>>> [664h 1636   2]                     PCI Path : 00,02
>>>>
>>>>
>>>> [666h 1638   1]            Device Scope Type : 01 [PCI Endpoint Device]
>>>> [667h 1639   1]                 Entry Length : 0A
>>>> [668h 1640   2]                     Reserved : 0000
>>>> [66Ah 1642   1]               Enumeration ID : 00
>>>> [66Bh 1643   1]               PCI Bus Number : 00
>>>>
>>>> [66Ch 1644   2]                     PCI Path : 1C,07
>>>>
>>>> [66Eh 1646   2]                     PCI Path : 00,04
>>>>
> 
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu