> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Tuesday, May 20, 2014 08:33
>
> On Wed, May 14, 2014 at 11:38:25AM +, Cornwall, Jay wrote:
> > Hi,
> >
> > I'm not sure why you're submitting this, Suravee?
> >
> > We already agreed that we need the extra mmu_notifier point, proposed
> > b
On Wed, May 14, 2014 at 11:38:25AM +, Cornwall, Jay wrote:
> Hi,
>
> I'm not sure why you're submitting this, Suravee?
>
> We already agreed that we need the extra mmu_notifier point, proposed
> by Joerg back in 2011, to eliminate the race. I had thought we were
> waiting on that to be implem
Roedel [j...@8bytes.org]
Sent: Wednesday, May 14, 2014 4:29 AM
To: Suthikulpanit, Suravee
Cc: iommu@lists.linux-foundation.org; Hurwitz, Sherry; Naru, Kim;
linux-ker...@vger.kernel.org; Cornwall, Jay
Subject: Re: [PATCH] iommu/amd: Fix for L2 race with VM invalidation
On Wed, May 14, 2014 at 01:34:
On Wed, May 14, 2014 at 01:34:12AM -0500, suravee.suthikulpa...@amd.com wrote:
> A low probability race exists with this fix. Translations received
> within the critical section to PTEs which are concurrently being
> invalidated may resolve to stale mappings.
Sorry, no. This patch can cause silent
From: Jay Cornwall
Do not disassociate the process page tables from a PASID during VM
invalidation. Invalidate the IOMMU TLB and IOTLBs before invalidation.
L2 translations may fail during VM range invalidation. The current
implementation associates an empty page table with a PASID within
the cr
