On Mar 6, 2014 5:25 PM, Stuart Yoder wrote:
>
>
>
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, February 20, 2014 4:44 PM
> > To: Yoder Stuart-B08248
> > Cc: Antonios Motakis; alex.william...@redhat.com;
> > kvm...@lists.cs.columbia.
On Mar 6, 2014 5:25 PM, Stuart Yoder wrote:
>
>
>
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, February 20, 2014 4:44 PM
> > To: Yoder Stuart-B08248
> > Cc: Antonios Motakis; alex.william...@redhat.com;
> > kvm...@lists.cs.columbia.
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, February 20, 2014 4:44 PM
> To: Yoder Stuart-B08248
> Cc: Antonios Motakis; alex.william...@redhat.com;
> kvm...@lists.cs.columbia.edu; iommu@lists.linux-foundation.org; linux-
> ker...@vger.kernel.
On Wed, 2014-02-19 at 14:07 +0800, Jiang Liu wrote:
> Current Intel DMAR/IOMMU driver assumes that all PCI devices
> associated
> with DMAR/RMRR/ATSR device scope arrays are created at boot time and
> won't change at runtime, so it caches pointers of associated PCI
> device
> object. That assumptio
There is a race condition between the existing clear/free code and the
hardware. The IOMMU is actually permitted to cache the intermediate
levels of the page tables, and doesn't need to walk the table from the
very top of the PGD each time. So the existing back-to-back calls to
dma_pte_clear_range(
