Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp2084412ybm; Thu, 23 May 2019 11:07:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFT4XXtVOaofJkqhQY061UCK9LrGLbB8VzHNrcbHv/vkyxVyBeKIaQa8i80SGVZFse87lH X-Received: by 2002:a17:90a:238d:: with SMTP id g13mr3172574pje.0.1558634854819; Thu, 23 May 2019 11:07:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558634854; cv=none; d=google.com; s=arc-20160816; b=gQSDcegjX0aNSL4kintOEKxZuNWXkRATgvKchwz8XZhzjWE+l6kI0ZxAsjmElyLvsU tu3Oj9FzJGwt+INZtEeh+jnMjH0CZZptw2dnRI6rlG+PTpxxvEfyKzQSYCwgzwzSGhF8 L6UqEsMlIGdnNyWrBsb0u5mNfuuIkJ3bwZZ4kgdOa5YlhePN/uA+0ynHbGVyWhquQt5T yxzFct4mt0HopGGQNwuviLs3PkXv2PSXTv2tFoabFbhXCscBrsuYrzi3LthMtRJTIv1H YEuMfG0lCJnw0ND1Zkb+XXA1AaDgcoI9AK5BmzNU6lbLO7/lgA4FFtTRmlO0hFHO3jO7 jGSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=WUnl8krSdJIZrg8zZP9jaRSGlXKkzsugv+A4jBilG3U=; b=ANyLStAhs/NAQ77yWcCJZ0aCN9/j7zCMv0Kq+HUZ0UyyvNv8fQGoaUjud9Bk46/uM5 M1RbWUdrD0+Z/3id1a8otM9c7aeGRmyuPMBJ3TuaXH8lGucoqkDMAGwVF/5+Scf7Q+66 ejLT6+2ejoR8Y7+p1BsLLSl4KeAMNiwXrjaCLq1rXn5/MXBH7PXedTl6PGzdA+7Cs71/ +BmHHIAI/8m1acAh6Ca6qEzx5hidMAYTVebsojYEQSSBvF+Wf3fcTSLzGM13FECcKFbw 0WbhTIFWQmKHR+Mnnwu4rwjPbzNLOA30ggYDFnn8pwUsuvkzqpHwJvzdC0V6nznKbThC 1dOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d24si248296pgm.405.2019.05.23.11.07.18; Thu, 23 May 2019 11:07:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387418AbfEWSFx (ORCPT + 99 others); Thu, 23 May 2019 14:05:53 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52020 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387408AbfEWSFx (ORCPT ); Thu, 23 May 2019 14:05:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AFFF4374; Thu, 23 May 2019 11:05:52 -0700 (PDT) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB46E3F5AF; Thu, 23 May 2019 11:05:50 -0700 (PDT) Subject: Re: [PATCH] swiotlb: sync buffer when mapping FROM_DEVICE To: Christoph Hellwig , Marek Szyprowski Cc: =?UTF-8?Q?Horia_Geant=c4=83?= , Konrad Rzeszutek Wilk , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-imx@nxp.com References: <20190522072018.10660-1-horia.geanta@nxp.com> <20190522123243.GA26390@lst.de> <6cbe5470-16a6-17e9-337d-6ba18b16b6e8@arm.com> <20190522130921.GA26874@lst.de> <20190522133400.GA27229@lst.de> <0c79721a-11cb-c945-5626-3d43cc299fe6@samsung.com> <20190523164332.GA22245@lst.de> From: Robin Murphy Message-ID: <49076a29-a0f5-f5f0-6c2a-a2180edd1674@arm.com> Date: Thu, 23 May 2019 19:05:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190523164332.GA22245@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/2019 17:43, Christoph Hellwig wrote: > On Thu, May 23, 2019 at 07:35:07AM +0200, Marek Szyprowski wrote: >> Don't we have DMA_BIDIRECTIONAL for such case? > > Not sure if it was intended for that case, but it definitively should > do the right thing for swiotlb, and it should also do the right thing > in terms of cache maintainance. > >> Maybe we should update >> documentation a bit to point that DMA_FROM_DEVICE expects the whole >> buffer to be filled by the device? > > Probably. Horia, can you try to use DMA_BIDIRECTIONAL? > Yes, in general that should be a viable option. I got rather focused on the distinction that a "partial" FROM_DEVICE mapping would still be allowed to physically prevent the device from making any reads, whereas BIDIRECTIONAL would not, but I suspect any benefit being lost there is mostly one of debugging visibility rather than appreciable security, and probably not enough to justify additional complexity on its own - I couldn't say off-hand how many IOMMUs actually support write-only permissions anyway. Whichever way, I'd certainly have no objection to formalising what seems to be the existing behaviour (both SWIOTLB and ARM dmabounce look consistent, at least) as something like "for the DMA_FROM_DEVICE direction, any parts of the buffer not written to by the device will become undefined". The IOMMU bounce page stuff is going to be another one in this boat, too. Robin.