From: Horia Geanta <horia.geanta@nxp.com> To: Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, dl-linux-imx <linux-imx@nxp.com> Subject: Re: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE Date: Thu, 23 May 2019 16:25:54 +0000 [thread overview] Message-ID: <AM0PR0402MB3476949ECC57B188E83B820B98010@AM0PR0402MB3476.eurprd04.prod.outlook.com> (raw) In-Reply-To: 0c79721a-11cb-c945-5626-3d43cc299fe6@samsung.com On 5/23/2019 8:35 AM, Marek Szyprowski wrote: > Hi Robin, > > On 2019-05-22 15:55, Robin Murphy wrote: >> On 22/05/2019 14:34, Christoph Hellwig wrote: >>> On Wed, May 22, 2019 at 02:25:38PM +0100, Robin Murphy wrote: >>>> Sure, but that should be irrelevant since the effective problem here >>>> is in >>>> the sync_*_for_cpu direction, and it's the unmap which nobbles the >>>> buffer. >>>> If the driver does this: >>>> >>>> dma_map_single(whole buffer); >>>> <device writes to part of buffer> >>>> dma_unmap_single(whole buffer); >>>> <contents of rest of buffer now undefined> >>>> >>>> then it could instead do this and be happy: >>>> >>>> dma_map_single(whole buffer, SKIP_CPU_SYNC); >>>> <device writes to part of buffer> >>>> dma_sync_single_for_cpu(updated part of buffer); >>>> dma_unmap_single(whole buffer, SKIP_CPU_SYNC); >>>> <contents of rest of buffer still valid> >>> >>> Assuming the driver knows how much was actually DMAed this would >>> solve the issue. Horia, does this work for you? In my particular case, input is provided as a scatterlist, out of which first N bytes are problematic (not written to by device and corrupted when swiotlb bouncing is needed), while remaining bytes (Total - N) are updated by the device. >> >> Ohhh, and now I've just twigged what you were suggesting - your >> DMA_ATTR_PARTIAL flag would mean "treat this as a read-modify-write of >> the buffer because we *don't* know exactly which parts the device may >> write to". So indeed if we did go down that route we wouldn't need any >> of the sync stuff I was worrying about (but I might suggest naming it >> DMA_ATTR_UPDATE instead). Apologies for being slow :) > > Don't we have DMA_BIDIRECTIONAL for such case? Maybe we should update > documentation a bit to point that DMA_FROM_DEVICE expects the whole > buffer to be filled by the device? > Or, put more bluntly, driver must not rely on previous data in the area mapped DMA_FROM_DEVICE. This limitation stems from the buffer bouncing mechanism of the swiotlb DMA API backend, which other backends might not suffer from (e.g. IOMMU). Btw, the device I am working on (caam crypto engine) is deployed in several SoCs configured differently - with or without an IOMMU (and coherent or non-coherent etc.). IOW it's a "power user" of the DMA API and I appreciate all the help in solving / clarifying this kind of implicit assumptions. Thanks, Horia
WARNING: multiple messages have this Message-ID (diff)
From: Horia Geanta <horia.geanta@nxp.com> To: Marek Szyprowski <m.szyprowski@samsung.com>, Robin Murphy <robin.murphy@arm.com>, Christoph Hellwig <hch@lst.de> Cc: dl-linux-imx <linux-imx@nxp.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Subject: Re: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE Date: Thu, 23 May 2019 16:25:54 +0000 [thread overview] Message-ID: <AM0PR0402MB3476949ECC57B188E83B820B98010@AM0PR0402MB3476.eurprd04.prod.outlook.com> (raw) In-Reply-To: 0c79721a-11cb-c945-5626-3d43cc299fe6@samsung.com On 5/23/2019 8:35 AM, Marek Szyprowski wrote: > Hi Robin, > > On 2019-05-22 15:55, Robin Murphy wrote: >> On 22/05/2019 14:34, Christoph Hellwig wrote: >>> On Wed, May 22, 2019 at 02:25:38PM +0100, Robin Murphy wrote: >>>> Sure, but that should be irrelevant since the effective problem here >>>> is in >>>> the sync_*_for_cpu direction, and it's the unmap which nobbles the >>>> buffer. >>>> If the driver does this: >>>> >>>> dma_map_single(whole buffer); >>>> <device writes to part of buffer> >>>> dma_unmap_single(whole buffer); >>>> <contents of rest of buffer now undefined> >>>> >>>> then it could instead do this and be happy: >>>> >>>> dma_map_single(whole buffer, SKIP_CPU_SYNC); >>>> <device writes to part of buffer> >>>> dma_sync_single_for_cpu(updated part of buffer); >>>> dma_unmap_single(whole buffer, SKIP_CPU_SYNC); >>>> <contents of rest of buffer still valid> >>> >>> Assuming the driver knows how much was actually DMAed this would >>> solve the issue. Horia, does this work for you? In my particular case, input is provided as a scatterlist, out of which first N bytes are problematic (not written to by device and corrupted when swiotlb bouncing is needed), while remaining bytes (Total - N) are updated by the device. >> >> Ohhh, and now I've just twigged what you were suggesting - your >> DMA_ATTR_PARTIAL flag would mean "treat this as a read-modify-write of >> the buffer because we *don't* know exactly which parts the device may >> write to". So indeed if we did go down that route we wouldn't need any >> of the sync stuff I was worrying about (but I might suggest naming it >> DMA_ATTR_UPDATE instead). Apologies for being slow :) > > Don't we have DMA_BIDIRECTIONAL for such case? Maybe we should update > documentation a bit to point that DMA_FROM_DEVICE expects the whole > buffer to be filled by the device? > Or, put more bluntly, driver must not rely on previous data in the area mapped DMA_FROM_DEVICE. This limitation stems from the buffer bouncing mechanism of the swiotlb DMA API backend, which other backends might not suffer from (e.g. IOMMU). Btw, the device I am working on (caam crypto engine) is deployed in several SoCs configured differently - with or without an IOMMU (and coherent or non-coherent etc.). IOW it's a "power user" of the DMA API and I appreciate all the help in solving / clarifying this kind of implicit assumptions. Thanks, Horia _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-05-23 16:26 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-22 7:20 [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE Horia Geantă 2019-05-22 7:20 ` Horia Geantă 2019-05-22 12:32 ` Christoph Hellwig 2019-05-22 12:32 ` Christoph Hellwig 2019-05-22 12:50 ` Robin Murphy 2019-05-22 12:50 ` Robin Murphy 2019-05-22 13:09 ` Christoph Hellwig 2019-05-22 13:09 ` Christoph Hellwig 2019-05-22 13:25 ` Robin Murphy 2019-05-22 13:25 ` Robin Murphy 2019-05-22 13:34 ` Christoph Hellwig 2019-05-22 13:34 ` Christoph Hellwig 2019-05-22 13:55 ` Robin Murphy 2019-05-22 13:55 ` Robin Murphy 2019-05-23 5:35 ` Marek Szyprowski 2019-05-23 5:35 ` Marek Szyprowski 2019-05-23 16:25 ` Horia Geanta [this message] 2019-05-23 16:25 ` Horia Geanta 2019-05-23 16:43 ` Christoph Hellwig 2019-05-23 16:43 ` Christoph Hellwig 2019-05-23 17:53 ` Horia Geanta 2019-05-23 17:53 ` Horia Geanta 2019-05-23 18:05 ` Robin Murphy 2019-05-23 18:05 ` Robin Murphy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=AM0PR0402MB3476949ECC57B188E83B820B98010@AM0PR0402MB3476.eurprd04.prod.outlook.com \ --to=horia.geanta@nxp.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=robin.murphy@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.