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: Sun, 8 Dec 2019 14:26:18 +0800 [thread overview]
Message-ID: <7979b838-e2c5-4064-490c-8e0884909715@linux.intel.com> (raw)
In-Reply-To: <20191207024118.uwwzthqifh2dca5q@cantor>
Hi,
On 12/7/19 10:41 AM, Jerry Snitselaar wrote:
> On Fri Dec 06 19, Jerry Snitselaar wrote:
>> On Sat Dec 07 19, Lu Baolu wrote:
>>> Hi Jerry,
>>>
>>> On 12/6/19 3:24 PM, Jerry Snitselaar wrote:
>>>> On Fri Dec 06 19, Lu Baolu wrote:
>>>> [snip]
>>>>>
>>>>> Can you please try below change? Let's check whether the afending
>>>>> address has been mapped for device 01.00.2.
>>>>>
>>>>> $ git diff
>>>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>>>> index db7bfd4f2d20..d9daf66be849 100644
>>>>> --- a/drivers/iommu/iommu.c
>>>>> +++ b/drivers/iommu/iommu.c
>>>>> @@ -663,6 +663,8 @@ static int
>>>>> iommu_group_create_direct_mappings(struct iommu_group *group,
>>>>> ret = iommu_map(domain, addr, addr, pg_size,
>>>>> entry->prot);
>>>>> if (ret)
>>>>> goto out;
>>>>> +
>>>>> + dev_info(dev, "Setting identity map [0x%Lx
>>>>> - 0x%Lx] for group %d\n", addr, addr + pg_size, group->id);
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> I am doubting that device 01.00.2 is not in the device scope of
>>>>>
>>>>> [ 4.485108] DMAR: RMRR base: 0x000000bdf6f000 end: 0x000000bdf7efff
>>>>>
>>>>> By the way, does device 01.00.2 works well after binding the driver?
>>>>>
>>>>
>>>> When I boot it with passthrough it doesn't get to a point where I can
>>>> login. I think the serial console on these systems is tied to the ilo,
>>>> so the conserver connection could be making things
>>>> worse. Unfortunately the system is remote. I should have more time now
>>>> to focus on debugging this.
>>>>
>>>> Attaching console output for the above patch.
>>>
>>> It seems that device 01.00.2 isn't in the scope of RMRR [base:
>>> 0x000000bdf6f000 end: 0x000000bdf7efff]. But it still tries to access
>>> the address within it, hence faults generated.
>>>
>>> You can check it with ACPI/DMAR table.
>>>
>>> Best regards,
>>> baolu
>>>
>>
>> I believe it is the 3rd endpoint device entry in dmar data below.
>> So question about request_default_domain_for_dev. Since a dma mapping
>> is already done for 1.00.0, and that sets the default_domain for the
>> group (I think), won't it bail out for 1.00.2 at this check?
>>
>> if (group->default_domain && group->default_domain->type == type)
>> goto out;
>>
>
> Or I guess request_default_domain_for_dev wouldn't even be called for
> 1.00.2.
> intel_iommu_add_device it wouldn't even call one of the request
> functions with 1.00.2 since domain->type would be dma from 1.00.0, and
> device_def_domain_type
> should return dma.
Can you please add some debug messages and check what really happens
here?
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-12-08 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 [this message]
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
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=7979b838-e2c5-4064-490c-8e0884909715@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).