From: Ting-Wei Lan <lantw44@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Kevin Tian <kevin.tian@intel.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
lantw44@gmail.com,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues
Date: Fri, 24 Jul 2015 00:41:51 +0800 [thread overview]
Message-ID: <55B1194F.6010800@gmail.com> (raw)
In-Reply-To: <55AE11E4020000780009380B@prv-mh.provo.novell.com>
Jan Beulich 於 西元2015年07月21日 15:33 寫道:
>>>> On 21.07.15 at 09:23, <kevin.tian@intel.com> wrote:
>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>> Sent: Tuesday, July 21, 2015 3:17 PM
>>
>>>>>> On 21.07.15 at 09:05, <kevin.tian@intel.com> wrote:
>>>>> From: Jan Beulich [mailto:JBeulich@suse.com]
>>>>> Sent: Tuesday, July 21, 2015 2:57 PM
>>>>>>>> On 21.07.15 at 02:57, <kevin.tian@intel.com> wrote:
>>>>>>> From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of Andrew
>>>>>> Cooper
>>>>>>> Sent: Monday, July 20, 2015 4:21 PM
>>>>>> This is the part which I don't quite understand. WC is essentially an UC
>>>>>> attribute with write buffer to accelerate the write efficiency. There
>>>>>> should be no correctness problem to use either WC or UC if i915 driver
>>>>>> wants WC.
>>>>>
>>>>> "Should" is too weak a term here: Using WC on the wrong piece of
>>>>> memory or without the necessary fencing can imo very well cause
>>>>> correctness problems (which would be hidden by WC -> UC
>>>>> conversion behind the driver's back).
>>>>>
>>>>
>>>> My point is about when i915 wants WC, then either UC (I suppose is
>>>> the case before that Linux commit) and WC (by that commit) has
>>>> no correctness problem. UC is more strict than WC. It's just performance
>>>> difference. It's not about using WC in wrong place when it's not desired.
>>>
>>> In this you assume there are no misguided attempts to request
>>> WC in the driver, which would have gone unnoticed as long as WC
>>> didn't become the effective attribute. And "misguided" here is
>>> meant to include cases where hardware errata may need taking
>>> care of.
>>
>> I don't understand this point. If it's misguided attempts it'd be
>> same on bare metal.
>
> Not if bare metal has a workaround in place depending on (or even
> implemented in) IOMMU code. Also iirc the reported said that a
> similar problem existed (exists?) on native too.
On 3.7 <= Linux < 4.2-rc2 without Xen, the screen output is broken, and
the system crashes after display server is started.
On Linux >= 4.2-rc2 without Xen, the screen output is normal because
this patch is added
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8b572a4
but these messages are showed every a few seconds. If I keep using it,
it will crash in about two hours.
DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr fdf70000
DMAR:[fault reason 05] PTE Write access is not set
On Linux >= 3.19 with Xen, the screen output is broken, and these
similar messages are showed.
(XEN) [VT-D]DMAR:[DMA Write] Request device [0000:00:02.0] fault addr
73fbff000, iommu reg = ffff82c000203000
(XEN) [VT-D]DMAR: reason 05 - PTE Write access is not set
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-07-23 16:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 19:05 [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues Ting-Wei Lan
2015-07-17 19:36 ` Andrew Cooper
2015-07-18 8:46 ` 藍挺瑋
2015-07-19 15:53 ` Julien Grall
2015-07-20 8:27 ` Andrew Cooper
2015-07-20 10:19 ` Julien Grall
2015-07-20 1:28 ` Tian, Kevin
2015-07-20 8:21 ` Andrew Cooper
2015-07-20 10:44 ` Ting-Wei Lan
2015-07-21 0:57 ` Tian, Kevin
2015-07-21 6:56 ` Jan Beulich
2015-07-21 7:05 ` Tian, Kevin
2015-07-21 7:16 ` Jan Beulich
2015-07-21 7:23 ` Tian, Kevin
2015-07-21 7:33 ` Jan Beulich
2015-07-23 16:41 ` Ting-Wei Lan [this message]
2015-07-20 8:46 ` Jan Beulich
2015-07-25 16:57 ` [PATCH v2] VT-d: add iommu=igfx " Ting-Wei Lan
2015-07-26 16:47 ` Andrew Cooper
2015-07-31 1:26 ` Tian, Kevin
2015-07-31 8:37 ` Ting-Wei Lan
2015-08-04 2:00 ` Tian, Kevin
2015-08-05 9:11 ` [PATCH v3] " Ting-Wei Lan
2015-08-05 12:18 ` Andrew Cooper
2015-08-05 13:35 ` Wei Liu
2015-08-05 17:10 ` [PATCH v4] " Ting-Wei Lan
2015-08-06 0:49 ` Tian, Kevin
2015-08-06 8:25 ` Wei Liu
2015-08-06 9:28 ` Ian Campbell
2015-07-20 12:12 ` [PATCH] VT-d: add iommu=igfx_off " Andrew Cooper
2015-07-20 12:24 ` Jan Beulich
2015-07-20 12:34 ` Andrew Cooper
2015-07-20 13:55 ` Jan Beulich
2015-07-20 14:12 ` Andrew Cooper
2015-07-20 14:25 ` Jan Beulich
2015-07-21 1:15 ` Tian, Kevin
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=55B1194F.6010800@gmail.com \
--to=lantw44@gmail.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.