From: Jan Beulich <jbeulich@suse.com>
To: Jason Andryuk <jandryuk@gmail.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
intel-gfx@lists.freedesktop.org,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: i915 dma faults on Xen
Date: Wed, 21 Oct 2020 14:52:59 +0200 [thread overview]
Message-ID: <a4dd7778-9bd4-00c1-3056-96d435b70d70@suse.com> (raw)
In-Reply-To: <CAKf6xpuTE4gBNe4YXPYh_hAMLaJduDuKL5_6aC4H=y6DRxaxvw@mail.gmail.com>
On 21.10.2020 14:45, Jason Andryuk wrote:
> On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné <roger.pau@citrix.com> wrote:
>> Hm, it's hard to tell what's going on. My limited experience with
>> IOMMU faults on broken systems there's a small range that initially
>> triggers those, and then the device goes wonky and starts accessing a
>> whole load of invalid addresses.
>>
>> You could try adding those manually using the rmrr Xen command line
>> option [0], maybe you can figure out which range(s) are missing?
>
> They seem to change, so it's hard to know. Would there be harm in
> adding one to cover the end of RAM ( 0x04,7c80,0000 ) to (
> 0xff,ffff,ffff )? Maybe that would just quiet the pointless faults
> while leaving the IOMMU enabled?
While they may quieten the faults, I don't think those faults are
pointless. They indicate some problem with the software (less
likely the hardware, possibly the firmware) that you're using.
Also there's the question of what the overall behavior is going
to be when devices are permitted to access unpopulated address
ranges. I assume you did check already that no devices have their
BARs placed in that range?
Jan
next prev parent reply other threads:[~2020-10-21 12:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 19:28 i915 dma faults on Xen Jason Andryuk
2020-10-14 19:37 ` Andrew Cooper
2020-10-15 11:31 ` Roger Pau Monné
2020-10-15 15:16 ` Jason Andryuk
2020-10-15 16:38 ` Tamas K Lengyel
2020-10-15 17:13 ` Jason Andryuk
2021-02-19 17:33 ` tboot UEFI and Xen (was Re: i915 dma faults on Xen) Jason Andryuk
2020-10-16 16:23 ` i915 dma faults on Xen Jason Andryuk
2020-10-21 9:58 ` Roger Pau Monné
2020-10-21 10:33 ` Jan Beulich
2020-10-21 10:51 ` Roger Pau Monné
2020-10-21 12:45 ` Jason Andryuk
2020-10-21 12:52 ` Jan Beulich [this message]
2020-10-21 13:36 ` Jason Andryuk
2020-10-21 13:59 ` Jan Beulich
2021-02-19 17:30 ` Jason Andryuk
2021-02-22 10:18 ` Roger Pau Monné
2021-02-22 12:49 ` Jason Andryuk
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=a4dd7778-9bd4-00c1-3056-96d435b70d70@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jandryuk@gmail.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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).