[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1321058267.2006.21.camel@shinybook.infradead.org>
Date: Sat, 12 Nov 2011 00:37:47 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, chrisw@...s-sol.org,
ddutile@...hat.com
Subject: Re: [PATCH] intel-iommu: Default to non-coherent for domains
unattached to iommus
On Fri, 2011-11-11 at 15:49 -0700, Alex Williamson wrote:
> To fix this, switch domain_update_iommu_coherency() to use the
> safer, non-coherent default for domains not attached to iommus.
That isn't a fix for the problem you described.
The problem is that changing a domain from coherent to non-coherent is
*broken*. It probably needs to flush the cache for the *entire* set of
page tables — not just the new context entry it adds.
You might have removed the *common* case where we trigger that bug, but
it certainly isn't a fix.
However, I'd be receptive to an argument that the situation you describe
is in fact the *only* time we'd have to switch from coherent to
non-coherent at run time, because the coherency is an all-or-nothing
characteristic of the chipset. Either all the IOMMUs are coherent, or
none of them, right? This brain-damage only affects the first chipsets
from before we worked out that cache incoherency was a *really* f*cking
stupid idea, doesn't it?
So if you were to ditch the whole idea of a per-domain runtime update,
and instead calculate a global value for 'iommu_coherency' at boot time,
by iterating over for_each_active_iommu()¹, I think that would be a
better way to deal with the issue. And you *could* really call that a
'fix'.
Make sense?
--
dwmw2
¹ just in *case* they ever differ
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5818 bytes)
Powered by blists - more mailing lists