Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6835571pxb; Wed, 17 Feb 2021 15:05:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyTY+i3VyvdGNJ2R47L0XJTNTa1S4O9qoWXwkL+SkkOss/Z9Cjq8SmXDzfQqJAhbPbUorwY X-Received: by 2002:aa7:cc98:: with SMTP id p24mr1168448edt.126.1613603122492; Wed, 17 Feb 2021 15:05:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613603122; cv=none; d=google.com; s=arc-20160816; b=fYaEBUulxlY6JWRl/y5CkVqmatZkqG5hb1ffeDIKxzFvpSRTH7TdzzzAfrLuANBnaU m7rifyWy3kol6Ywy9mr4tNBDBUS2Ya0rd9GddkHQ93RsQQf9GjbL91uDVbcRQghNdQ6N 6ogzs2AqC+SwBxA8gz+ELnYXYzTEXxc1Q93XboOSbjthx3KNjgCriq7T2alKbr/YNl33 UOfWCW4q67FFEbi/Ex8W39QFDtSwBw+dZ3RfOT6vetWb3LoJzuPqxZsgJG7suPxdu04k GSgOWc3P0rZun/zqLcLZ6lPXBOEtznMTfCbuiiY8YEf6K8wlUGt6mqyNdqssAJhuPiOp 8oCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:dkim-signature:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from; bh=Zcp6FwQOo6uCl+bAC2DWEr4Viwiu5nIBT+YN6D2qruU=; b=c2eJvK0k65dVVtVHeqe2NT1BW0YX28yRVteL33W18JxWmykjRC8zOlghRjAZzEMf3V RZQy0/yNGjdqzPxGx5KXbmNm/WGVg4efDVWb7WKlu4t/92gDAuLPBqQ+sg8qzsOA2zwi La9iT3fJxrUVQIkf8NTCSy6ZRTLfjBRwqJE159YQNAA0S5hsoLRItrViFeb0w8gP5eme Y3W7tWVW74gqms/NL8mVmCZsOH7z1PHVxH5RWWA4P85R4wqAdJ7sPH6BUIZibocoeT3L 1YZMyiq1F7imx8TGNMchlfsDY8o5YzNvMMoun68eNyTy1+VzPa6VoaFwQQeWV1R6W68p qDPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=AXb+ut3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si2250966edc.553.2021.02.17.15.04.52; Wed, 17 Feb 2021 15:05:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=AXb+ut3o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231462AbhBQXBk (ORCPT + 99 others); Wed, 17 Feb 2021 18:01:40 -0500 Received: from hqnvemgate25.nvidia.com ([216.228.121.64]:16785 "EHLO hqnvemgate25.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbhBQXBk (ORCPT ); Wed, 17 Feb 2021 18:01:40 -0500 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Wed, 17 Feb 2021 15:00:59 -0800 Received: from nvdebian.localnet (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Feb 2021 23:00:56 +0000 From: Alistair Popple To: CC: Christoph Hellwig , Jason Gunthorpe , John Hubbard , Daniel Vetter , "Nouveau Dev" , Ben Skeggs , "Andrew Morton" , Linux Doc Mailing List , Linux Kernel Mailing List , , dri-devel , Ralph Campbell , Jerome Glisse Subject: Re: [PATCH 0/9] Add support for SVM atomics in Nouveau Date: Thu, 18 Feb 2021 10:00:54 +1100 Message-ID: <6616185.Wbe1NtApLk@nvdebian> In-Reply-To: <20210211075510.GA2368090@infradead.org> References: <20210209010722.13839-1-apopple@nvidia.com> <20210210175913.GO4718@ziepe.ca> <20210211075510.GA2368090@infradead.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1613602859; bh=Zcp6FwQOo6uCl+bAC2DWEr4Viwiu5nIBT+YN6D2qruU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type: X-Originating-IP:X-ClientProxiedBy; b=AXb+ut3ot7Odaa4NfndUdnHlBWh/CmCbxa90e7XGqYDqOl0itTA0ey/0xdqSoXbA2 JlMNydOcVXGiAO1uyIryQXCh6IJNMB5+ajbf7PvbtDcER0T/TTnEqkgpU2USIY0Ya+ NqYaHlrJc7yam1VcZFkBNUvumzVGyvnQedJAd2+hs20Ac8NKfjzT6p3t31zwxNt/Hq gR+sHNOCuxdnohI6TOW7pnPo+iGVNWMyVlv0cNOIZszQSsdsXR69vsDcRIyKwiHLuU QHMPy9U3pXXKcoKf2xltHJbe92pWiS2sWG6fQJuE1wnVVzjgSmr5R0ufLguVI0LbOK oydiyGx+ixcIg== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, 11 February 2021 6:55:10 PM AEDT Christoph Hellwig wrote: > On Wed, Feb 10, 2021 at 01:59:13PM -0400, Jason Gunthorpe wrote: > > Really what you want to do here is leave the CPU page in the VMA and > > the page tables where it started and deny CPU access to the page. Then > > all the proper machinery will continue to work. > > > > IMHO "migration" is the wrong idea if the data isn't actually moving. > > Agreed. I chose "migration" because device private pages seemed like a good way of reusing existing code to do what was required (a callback on CPU access). However I have been reworking this to use mmu notifiers as the callback and it seems to simplify some things nicely so think I also agree. It removes the requirement for the pin as well which is nice, I'll post it as a v2 soon. - Alistair