<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#c9">Comment # 9</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:dwmw2@infradead.org" title="David Woodhouse <dwmw2@infradead.org>"> David Woodhouse</a> <pre>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. 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. 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? 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>