[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]

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

--- Comment #10 from Ting-Wei Lan <lantw44 at gmail.com> ---
(In reply to David Woodhouse from comment #9)
> 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.
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03642.html
http://lists.xenproject.org/archives/html/xen-devel/2015-07/msg03723.html

> 
> 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:
https://bugs.freedesktop.org/show_bug.cgi?id=91127

Bisect result:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=edef7e6

Non-Xen case is partially fixed now. Screen output works fine, but the system
crashes after using for several hours.

> 
> 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/6dc4a0f8/attachment-0001.html>