<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [xen iommu] After upgrading to Linux 3.19, desktop no longer works in Xen 4.5.0 dom0" href="https://bugs.freedesktop.org/show_bug.cgi?id=90037#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [xen iommu] After upgrading to Linux 3.19, desktop no longer works in Xen 4.5.0 dom0" href="https://bugs.freedesktop.org/show_bug.cgi?id=90037">bug 90037</a> from <a class="email" href="mailto:lantw44@gmail.com" title="Ting-Wei Lan <lantw44@gmail.com>"> Ting-Wei Lan</a> <pre>(In reply to David Woodhouse from <a href="show_bug.cgi?id=90037#c9">comment #9</a>) > It's odd that it was triggered (in the Xen case) by a PAT patch. > > What was the actual effect of that patch on the caching mode used by the > machine in question? > > > [ +0.005382] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap > c0000020230272 ecap 1000 > > cap & (1<<4) is set, which is the RWBF bit: > > 1: Indicates software must explicitly flush > the write buffers to ensure updates made to > memory-resident remapping structures are > visible to hardware. > > ecap & (1<<0) is clear, which is the Coherency bit: > > This field indicates if hardware access to the > root, context, extended-context and > interrupt-remap tables, and second-level > paging structures for requests-without- > PASID, are coherent (snooped) or not. > • 0:Indicates hardware accesses to > remapping structures are non-coherent. > > So basically this hardware is in a mode where the IOMMU page tables are > non-cache coherent. Not only do you have to clflush every cache line in the > page tables to main memory when you write it, but you *also* have to jump > through hoops to ensure that the writes are pushed through chipset-specific > write buffers (see §6.8 of the VT-d specification). > > That may help to explain why a seemingly innocent PAT change might have > triggered something odd. But it would be good to know precisely what went > wrong. Can you tell me how can I test it or provide me a link that describes steps to get needed information? I am not familiar with VT-d spec. There were discussion on Xen-devel when I tried to make a workaround. <a href="http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03642.html">http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03642.html</a> <a href="http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03723.html">http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03723.html</a> > > Also, does it help to add 'iommu=pt' to the kernel command line? That would > make the IOMMU use a 1:1 mapping of all memory, rather than dynamically > setting up mappings. No, screen output is still broken. > > You say it can be reproduced without Xen, with Linux >= 3.7 — can you show > the details of that please? And if it doesn't occur in 3.6, can you also > bisect the non-Xen case to find when it started happening, please? Non-Xen case is already reported here: <a class="bz_bug_link bz_status_NEW " title="NEW - Graphics problems with intel_iommu=on on Linux >= 3.7" href="show_bug.cgi?id=91127">https://bugs.freedesktop.org/show_bug.cgi?id=91127</a> Bisect result: <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=edef7e6">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=edef7e6</a> Non-Xen case is partially fixed now. Screen output works fine, but the system crashes after using for several hours. > > Thanks,</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>