From: Lu Baolu <baolu.lu@linux.intel.com>
To: Jerry Snitselaar <jsnitsel@redhat.com>,
iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>
Subject: Re: dmar pte read access not set error messages on hp dl388 gen8 systems
Date: Tue, 10 Dec 2019 14:26:42 +0800 [thread overview]
Message-ID: <9b7297bd-fd26-8169-29c5-e662ef700051@linux.intel.com> (raw)
In-Reply-To: <20191210061620.gp3qe2ljq3hhbetx@cantor>
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
next prev parent reply other threads:[~2019-12-10 6:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 6:34 dmar pte read access not set error messages on hp dl388 gen8 systems Jerry Snitselaar
2019-12-02 6:41 ` Lu Baolu
2019-12-02 7:14 ` Jerry Snitselaar
2019-12-02 16:13 ` Jerry Snitselaar
2019-12-03 1:59 ` Lu Baolu
2019-12-03 9:56 ` Jerry Snitselaar
2019-12-04 0:17 ` Lu Baolu
2019-12-04 20:53 ` Jerry Snitselaar
2019-12-05 1:39 ` Lu Baolu
2019-12-05 2:25 ` Jerry Snitselaar
2019-12-05 2:44 ` Lu Baolu
2019-12-05 2:53 ` Jerry Snitselaar
2019-12-06 1:52 ` Lu Baolu
2019-12-06 7:24 ` Jerry Snitselaar
2019-12-07 1:53 ` Lu Baolu
2019-12-07 2:29 ` Jerry Snitselaar
2019-12-07 2:41 ` Jerry Snitselaar
2019-12-08 6:26 ` Lu Baolu
2019-12-10 0:52 ` Jerry Snitselaar
2019-12-10 1:29 ` Lu Baolu
2019-12-10 3:47 ` Jerry Snitselaar
2019-12-10 5:03 ` Lu Baolu
2019-12-10 5:18 ` Jerry Snitselaar
2019-12-10 5:43 ` Lu Baolu
2019-12-10 22:12 ` Jerry Snitselaar
2019-12-10 5:43 ` Jerry Snitselaar
2019-12-10 6:16 ` Jerry Snitselaar
2019-12-10 6:26 ` Lu Baolu [this message]
2019-12-10 7:44 ` Jerry Snitselaar
2019-12-08 6:04 ` Lu Baolu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b7297bd-fd26-8169-29c5-e662ef700051@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).