From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30520C433E6 for ; Wed, 10 Feb 2021 18:06:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0894664DD6 for ; Wed, 10 Feb 2021 18:06:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233892AbhBJSFU (ORCPT ); Wed, 10 Feb 2021 13:05:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233739AbhBJR74 (ORCPT ); Wed, 10 Feb 2021 12:59:56 -0500 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C93CDC061574 for ; Wed, 10 Feb 2021 09:59:15 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id l11so1277880qvt.1 for ; Wed, 10 Feb 2021 09:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=jW9PVjGrRwIiTu0DvrBNx4ykL4I0ErasGCeEaMHeyrXRbfEG9LB3dcE8vE11UBawk6 1G1tcdRNTWBDtUg+fhfGsQMXOWfqjp3mTLwZKFq4HmTvwSr/K8tGSYW63Zm+KpQxHBXW u0ZOrWnXE5JBPOQyNkpBsjDIpzJF/xZBBZ9sBVx4nngGJfwe8dUE8XiCc/Io+j7LyXb3 qrq9PeYWhfP2y1Eo2XwOk5F4UEKCmphlVy4z7L2moVXVcz43s9cOi+RdntHzTecyr9XT 0EAPy3emAM7JVX2q3gq8vXafguG5d+qLtIeyiWB7Whu98AaOeG5oA/d4Anm2Sc/eA5pZ rwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=euZrmFoFApPI2n2skX2AYuCb2kRM6f/j4GX+ojsaRoviZxlPdwRNxXyqVdfy85FNJ9 d/MfsRig6raxlAQ7gzNiLxSboF9L+4mxrKX1Z1FVCT0h9aI2u54KS2LvdI5EmVZQFQIx /NF2khBasON1krjEFWVu0cvGdssfDuwbpphKoFSONMj56sTI05rvWy7s7A9tY/9Bc33p EGge+CLFz1z5Dnnr9t3GgxIOnnxecFe5n4gMcK+1+4juJDJuy+yLXQZdMkROaUpe0qvA lg0AvwOrFOm0OL9Oig429uXtNjex6o632B3UCJ+ZHABBWtuu+lJKM6sQPjxlM/ExfmN0 56cw== X-Gm-Message-State: AOAM532PEZq8x33GPEOezOcmMGd4bUB6pcxAp7uTJGTU3q8j8fZIJZKq qWOlD8vqIRBREqfdKCgfxeEddQ== X-Google-Smtp-Source: ABdhPJxwZzRaoXxpNKuY9U9fnfERIckZW7aYN7mA/qmqVG4TxZ7Frx9umWXL+42aGA2CymOfvFagoA== X-Received: by 2002:a0c:ed42:: with SMTP id v2mr3900087qvq.15.1612979954649; Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id p16sm1742656qtq.24.2021.02.10.09.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1l9tlh-006895-Mz; Wed, 10 Feb 2021 13:59:13 -0400 Date: Wed, 10 Feb 2021 13:59:13 -0400 From: Jason Gunthorpe To: John Hubbard Cc: Daniel Vetter , Alistair Popple , Linux MM , Nouveau Dev , Ben Skeggs , Andrew Morton , Linux Doc Mailing List , Linux Kernel Mailing List , kvm-ppc@vger.kernel.org, dri-devel , Ralph Campbell , Jerome Glisse Subject: Re: [PATCH 0/9] Add support for SVM atomics in Nouveau Message-ID: <20210210175913.GO4718@ziepe.ca> References: <20210209010722.13839-1-apopple@nvidia.com> <3426910.QXTomnrpqD@nvdebian> <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote: > This direction sounds at least...possible. Using MMU notifiers instead of pins > is definitely appealing. I'm not quite clear on the callback idea above, but > overall it seems like taking advantage of the ZONE_DEVICE tracking of pages > (without having to put anything additional in each struct page), could work. It isn't the ZONE_DEVICE page that needs to be tracked. 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. Jason From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2377AC433E9 for ; Wed, 10 Feb 2021 17:59:18 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CAC0864D9E for ; Wed, 10 Feb 2021 17:59:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAC0864D9E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=nouveau-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5990A6ECB4; Wed, 10 Feb 2021 17:59:17 +0000 (UTC) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3F5416ECB4 for ; Wed, 10 Feb 2021 17:59:16 +0000 (UTC) Received: by mail-qv1-xf2f.google.com with SMTP id p6so1255143qvm.12 for ; Wed, 10 Feb 2021 09:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=jW9PVjGrRwIiTu0DvrBNx4ykL4I0ErasGCeEaMHeyrXRbfEG9LB3dcE8vE11UBawk6 1G1tcdRNTWBDtUg+fhfGsQMXOWfqjp3mTLwZKFq4HmTvwSr/K8tGSYW63Zm+KpQxHBXW u0ZOrWnXE5JBPOQyNkpBsjDIpzJF/xZBBZ9sBVx4nngGJfwe8dUE8XiCc/Io+j7LyXb3 qrq9PeYWhfP2y1Eo2XwOk5F4UEKCmphlVy4z7L2moVXVcz43s9cOi+RdntHzTecyr9XT 0EAPy3emAM7JVX2q3gq8vXafguG5d+qLtIeyiWB7Whu98AaOeG5oA/d4Anm2Sc/eA5pZ rwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=pSz4NJurBQPdoJLpc1OrbD0KIKCxpdxdGI4/bnHx6UcNV7EUN2hXpAXfSVeKxcPaEB wCwDbSNg/kj5Bzr8HFf1MrMH4t4kCFd5Ovl4NIzsdQavsZrx+CajQjtABUQaCCrljiw+ x7kcq1qUPOb9bmhqfXd0jJZ9jZJgj29qCjmJKx56ft8qLlDOiR4Vo74pkh4QfWJ9FA4B TMvsx87iwWdPuNP3pnfmWJ4kPdGw5zcBrKHJuIeKQ415oe9C4lP1mmg00A0pItgUSKSd C5TbycvGaXVvlZyDtK3rk/T9/7Ow3pLZ75+122XKC6EF0/MKM3vODwGViMExDJLeJZVF +vgw== X-Gm-Message-State: AOAM531+0BBiFiBigy27I5y8gzL5aR1/aUBTDXLZZyLIrB/7CVry3Ac6 doBfeG0SMzHBux3luHo1sU2Sag== X-Google-Smtp-Source: ABdhPJxwZzRaoXxpNKuY9U9fnfERIckZW7aYN7mA/qmqVG4TxZ7Frx9umWXL+42aGA2CymOfvFagoA== X-Received: by 2002:a0c:ed42:: with SMTP id v2mr3900087qvq.15.1612979954649; Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id p16sm1742656qtq.24.2021.02.10.09.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1l9tlh-006895-Mz; Wed, 10 Feb 2021 13:59:13 -0400 Date: Wed, 10 Feb 2021 13:59:13 -0400 From: Jason Gunthorpe To: John Hubbard Message-ID: <20210210175913.GO4718@ziepe.ca> References: <20210209010722.13839-1-apopple@nvidia.com> <3426910.QXTomnrpqD@nvdebian> <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> Subject: Re: [Nouveau] [PATCH 0/9] Add support for SVM atomics in Nouveau X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ralph Campbell , Linux Doc Mailing List , Nouveau Dev , dri-devel , Alistair Popple , Linux Kernel Mailing List , kvm-ppc@vger.kernel.org, Linux MM , Ben Skeggs , Daniel Vetter , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote: > This direction sounds at least...possible. Using MMU notifiers instead of pins > is definitely appealing. I'm not quite clear on the callback idea above, but > overall it seems like taking advantage of the ZONE_DEVICE tracking of pages > (without having to put anything additional in each struct page), could work. It isn't the ZONE_DEVICE page that needs to be tracked. 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. Jason _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D81F4C433E0 for ; Wed, 10 Feb 2021 17:59:18 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7CE0D64E6F for ; Wed, 10 Feb 2021 17:59:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CE0D64E6F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 678CF6ECB8; Wed, 10 Feb 2021 17:59:17 +0000 (UTC) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by gabe.freedesktop.org (Postfix) with ESMTPS id E4C0D6ECB4 for ; Wed, 10 Feb 2021 17:59:15 +0000 (UTC) Received: by mail-qv1-xf36.google.com with SMTP id t18so1261029qvn.8 for ; Wed, 10 Feb 2021 09:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=jW9PVjGrRwIiTu0DvrBNx4ykL4I0ErasGCeEaMHeyrXRbfEG9LB3dcE8vE11UBawk6 1G1tcdRNTWBDtUg+fhfGsQMXOWfqjp3mTLwZKFq4HmTvwSr/K8tGSYW63Zm+KpQxHBXW u0ZOrWnXE5JBPOQyNkpBsjDIpzJF/xZBBZ9sBVx4nngGJfwe8dUE8XiCc/Io+j7LyXb3 qrq9PeYWhfP2y1Eo2XwOk5F4UEKCmphlVy4z7L2moVXVcz43s9cOi+RdntHzTecyr9XT 0EAPy3emAM7JVX2q3gq8vXafguG5d+qLtIeyiWB7Whu98AaOeG5oA/d4Anm2Sc/eA5pZ rwJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mEPuatLoyym+J6ItA3BIfCEOLL8sQ3QwAzMr1dNPupk=; b=adiHq74prREjznrsoZneioPhnYLwlvASDLEU+yjEFNQnQ/fs26dAZXZrstx4CDygV0 z1B64lhyR09sqcJqaKTV4qDslJPsClbQHClLqc+reSf91XsyWjzCMbOBspbB/c2kMbub a9Bo+vAr1P8RM7eYNwRMc0rmI+frwtZqXPnAFxCzDpxxeBeYLtKASuAEc4sGrZgNaPpy xmRO/jibhK3e9rqTbgjpKliDbKMLthla9lEWMf1iLpOwra/XntIw3iB5cgml1vmSV15R KJcz6wUSs7yQFYMplHm+YXn257qkeCxb/AQSPg83x9TAgpci1fr5IcFfxRnez/ZGCT3q DgzQ== X-Gm-Message-State: AOAM531paS4FcozFcDdTy6EaTzpDKwNyCJ5FKPLc9xkz6lRCU/jdnuly yxZaLlS9KITc2xDAUE5LLtX3Zw== X-Google-Smtp-Source: ABdhPJxwZzRaoXxpNKuY9U9fnfERIckZW7aYN7mA/qmqVG4TxZ7Frx9umWXL+42aGA2CymOfvFagoA== X-Received: by 2002:a0c:ed42:: with SMTP id v2mr3900087qvq.15.1612979954649; Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id p16sm1742656qtq.24.2021.02.10.09.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 09:59:14 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1l9tlh-006895-Mz; Wed, 10 Feb 2021 13:59:13 -0400 Date: Wed, 10 Feb 2021 13:59:13 -0400 From: Jason Gunthorpe To: John Hubbard Subject: Re: [PATCH 0/9] Add support for SVM atomics in Nouveau Message-ID: <20210210175913.GO4718@ziepe.ca> References: <20210209010722.13839-1-apopple@nvidia.com> <3426910.QXTomnrpqD@nvdebian> <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ralph Campbell , Linux Doc Mailing List , Nouveau Dev , dri-devel , Alistair Popple , Linux Kernel Mailing List , kvm-ppc@vger.kernel.org, Linux MM , Jerome Glisse , Ben Skeggs , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote: > This direction sounds at least...possible. Using MMU notifiers instead of pins > is definitely appealing. I'm not quite clear on the callback idea above, but > overall it seems like taking advantage of the ZONE_DEVICE tracking of pages > (without having to put anything additional in each struct page), could work. It isn't the ZONE_DEVICE page that needs to be tracked. 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. Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Date: Wed, 10 Feb 2021 17:59:13 +0000 Subject: Re: [PATCH 0/9] Add support for SVM atomics in Nouveau Message-Id: <20210210175913.GO4718@ziepe.ca> List-Id: References: <20210209010722.13839-1-apopple@nvidia.com> <3426910.QXTomnrpqD@nvdebian> <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> In-Reply-To: <57fe0deb-8bf6-d3ee-3545-11109e946528@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: John Hubbard Cc: Daniel Vetter , Alistair Popple , Linux MM , Nouveau Dev , Ben Skeggs , Andrew Morton , Linux Doc Mailing List , Linux Kernel Mailing List , kvm-ppc@vger.kernel.org, dri-devel , Ralph Campbell , Jerome Glisse On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote: > This direction sounds at least...possible. Using MMU notifiers instead of pins > is definitely appealing. I'm not quite clear on the callback idea above, but > overall it seems like taking advantage of the ZONE_DEVICE tracking of pages > (without having to put anything additional in each struct page), could work. It isn't the ZONE_DEVICE page that needs to be tracked. 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. Jason