[Bug 90037] [xen iommu] After upgrading to Linux 3.19, desktop no longer works in Xen 4.5.0 dom0

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 18 07:52:13 PDT 2015


https://bugs.freedesktop.org/show_bug.cgi?id=90037

--- Comment #9 from David Woodhouse <dwmw2 at infradead.org> ---
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,

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20150818/2455a1a9/attachment.html>


More information about the intel-gfx-bugs mailing list