On Thu, 17 May 2018 10:45:44 +0800 Peter Xu <pet...@redhat.com> wrote:
> On Wed, May 16, 2018 at 09:57:40PM +0800, Jason Wang wrote: > > > > > > On 2018年05月16日 14:30, Peter Xu wrote: > > > On Fri, May 04, 2018 at 11:08:01AM +0800, Peter Xu wrote: > > > > v2: > > > > - fix patchew code style warnings > > > > - interval tree: postpone malloc when inserting; simplify node remove > > > > a bit where proper [Jason] > > > > - fix up comment and commit message for iommu lock patch [Kevin] > > > > - protect context cache too using the iommu lock [Kevin, Jason] > > > > - add vast comment in patch 8 to explain the modify-PTE problem > > > > [Jason, Kevin] > > > We can hold a bit on reviewing this series. Jintack reported a scp > > > DMAR issue that might happen even with L1 guest with this series, and > > > the scp can stall after copied tens or hundreds of MBs randomly. I'm > > > still investigating the problem. This problem should be related to > > > deferred flushing of VT-d kernel driver, since the problem will go > > > away if we use "intel_iommu=on,strict". However I'm still trying to > > > figure out what's the thing behind the scene even with that deferred > > > flushing feature. > > > > I vaguely remember recent upstream vfio support delayed flush, maybe it's > > related. > > I'm a bit confused on why vfio is related to the deferred flushing. > Could you provide a pointer for this? Perhaps referring to this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bd06f5a486c06023a618a86e8153b91d26f75f4 Rather than calling iommu_unmap() for each chunk of a mapping we'll make multiple calls to iommu_unmap_fast() and flush with iommu_tlb_sync() to defer and batch the hardware flushing. Thanks, Alex
