Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4718647imu; Tue, 8 Jan 2019 05:13:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN7MSCBQ/PjxO2R1WvMTpbczka/sMJ+2b5k5vdA4v0F83IobldvQ5mQmgoM+L+0QgZ+Yw7Qt X-Received: by 2002:a17:902:48:: with SMTP id 66mr1702444pla.68.1546953228159; Tue, 08 Jan 2019 05:13:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546953228; cv=none; d=google.com; s=arc-20160816; b=0Oz/hY93DBFjFck2IhWUU6ywFhXjsU6HEwLEQxU1oP7GbHgcb7ljGCiI9fvIEKocGO 9Wzc6VGKabUMlfnTQcCd1gTtbTeUE2VjlJjuNbrrMz2J8oe4dYOrQS1zkYECn/sE215c +RhFZu/tXsvMo9+IBWRqJgPIvs1H1W5FII8L7JMaE+WFQIQPJkkfGC5fGsuIOBh6NfOb gRFMsm6sEnWS+qwLdaV4Q0ewKt9mhKE9yoIJvqzWmo0VW6cyzpX/FnBU8QoN3bqGMay0 v3euGrC8AWTlErSlfHyWI9QSGbS0usxShX9IYxihE7iQIUunz69oTMzlfV4RD+Ng0U0q GFDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=MuI6zbcKMrkGzrk/5SZ5F3iNilElTjI3p/mteFT9Bfo=; b=uAI8A3GSGQp0/kPeT5cE63mLDHYZsvGZy1QBOtYywt4prJL1AHkj+FAdgJrAfkV81x L16IPLLFRSPYajFa8uJdOSJAgMC2yeUfEmrZIGxIC7bFZZY4rp/r1H317S9f2HCi29Cs rGqYI4UXNtm+WklSYL3iFlIaHFbY4ESLHyw823Q9N0WM6HqGjuI71hxgWDtcL+3Pvzrh BKQ9N4ch4hlWP5/JK+TxzRtNr3QSVBt3+YnjfH1mU8rf8THrs/iHa//JkeB9Mdc6ib2W a4mxVB1wDMlOnVkfk/byi0YH/P+wcMEqJOnlHJM2CoC3dkjbuRxmkrzfvowraMNkAlG9 Fzzw== 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 b3si3963802pld.282.2019.01.08.05.13.32; Tue, 08 Jan 2019 05:13:48 -0800 (PST) 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 S1728211AbfAHNM3 (ORCPT + 99 others); Tue, 8 Jan 2019 08:12:29 -0500 Received: from verein.lst.de ([213.95.11.211]:34195 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726129AbfAHNM3 (ORCPT ); Tue, 8 Jan 2019 08:12:29 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id E610768C8E; Tue, 8 Jan 2019 14:12:27 +0100 (CET) Date: Tue, 8 Jan 2019 14:12:27 +0100 From: "hch@lst.de" To: Thomas Hellstrom Cc: "hch@lst.de" , "dri-devel@lists.freedesktop.org" , Linux-graphics-maintainer , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" Subject: Re: fix DMA ops layering violations in vmwgfx Message-ID: <20190108131227.GB6003@lst.de> References: <20190105080108.14837-1-hch@lst.de> <99091bb861e21d5bb4182f08dedbc494c637cc0f.camel@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99091bb861e21d5bb4182f08dedbc494c637cc0f.camel@vmware.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 08, 2019 at 09:51:45AM +0000, Thomas Hellstrom wrote: > Hi, Christoph, > > On Sat, 2019-01-05 at 09:01 +0100, Christoph Hellwig wrote: > > Hi Thomas, > > > > vmwgfx has been doing some odd checks based on DMA ops which rely > > on deep DMA mapping layer internals, and I think the changes in > > Linux 4.21 finally broke most of these implicit assumptions. > > Thanks. > What we're really trying to do here is to try to detect the situation > where DMA remapping using hardware IOMMUs is going on but memory is > still coherent, since the driver can currently only work with coherent > memory[1]. Currently we use intel_iommu_enabled to detect this > situation, but it would be really helpful if there were a generic bool > that advertizes this situation since we need to deal with other IOMMUs > as well going forward. Any suggestion? I'm missing the link of the [1] reference above. But if you need coherent memory you should simply always use dma_alloc_coherent, that is the only gurantee you get. If you use any other dma mapping methods you will otherwise need to explicitly transfer ownership by mapping/ unmapping or using dma_sync* before and after every device access. And the whole DMA API bypass using the phys mode is something that I'd really prefer not to see in any driver as it tends to cause major problems sooner or later.