Hi Casey looking at the debug output i got from Harsh it still looks like a bug in the code. [ 538.284589] __domain_mapping nr_pages 0x1 [ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len 0x38 pteval 0x3cbce3003 phys_pfn 0x3cbce3 [ 538.284604] chelsio driver - offset 4110 len 56 dma addr f291000e dma len 56 [ 538.284667] DMAR: DRHD: handling fault status reg 2 [ 538.290017] DMAR: [DMA Write] Request device [02:00.4] fault addr f2910000 [fault reason 05] PTE Write access is not set somehow when crypto_authenc_encrypt() -> scatterwalk_ffwd()-> sg_set_page() ->sg_set_page(dst, sg_page(src), src->length - len, src->offset + len); src->offset + len gets set as sg->offset in sg_set_page(). Either the assumption that there should be room is incorrect, or some higher order crypto code that ends up setting the offset did the wrong calculation. if src->offset is already towards the end of the page, then offset+len will go beyond the end of page. On Wed, Sep 27, 2017 at 09:29:23PM +0000, Casey Leedom wrote: > Hey Raj, > > Let us know if you need help in gathering more debugging information. For > the time being we've decided to ERRATA the use of the Intel I/O MMU with > IPsec till we Root Cause the issue. But this is still at the top of Harsh's > bug list. > > With Robin's comments, I'm almost sure that the: > > (iov_pfn + sg->offset) << VTD_PAGE_SHIFT) true, but this is the IOVA- IO Virtual address generated by the dma_map call. Thought in cases when sg->offset is beyond a page, then the new iov_pfn should fall on the next page. But we can't randomly adjust here, unless IOMMU has also allocated IOVA for the page overflow. Cheers, Ashok
