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

[Jerry Snitselaar <jsnitsel@redhat.com>]

On Tue Dec 10 19, Lu Baolu wrote:
>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
>

I will send a patch tomorrow. In the case where you have
default passthrough enabled, if the default domain type
for the first device in a group is dma the call will fail, because
iommu_group_create_direct_mappings uses group->default_domain and
that will have an identity type until group->default_domain gets
set right after the iommu_group_create_direct_mappings call.

Regards,
Jerry

>>
>>>>>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