Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp284562imn; Fri, 29 Jul 2022 06:52:20 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v2N8zE/pd5rwlo7Pf3Ym6FKfYTwM2mJMajI74hJD84zsDPfjfaQXugRpc8/xTF9M+ALQx4 X-Received: by 2002:a05:6402:3591:b0:43b:e8c8:a716 with SMTP id y17-20020a056402359100b0043be8c8a716mr3629116edc.356.1659102740581; Fri, 29 Jul 2022 06:52:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659102740; cv=none; d=google.com; s=arc-20160816; b=ORVsi85uMBFR27WsokMXASG2ouBtrGSUBXXu2uOXyOxuUSZFMQEFaX/1mH0JoKWNjy DvYKOJ1Ey2iBJnJ+VGPjtTGiHC0FwWmaOgEqGkymOyQtPhteQbUNpFTOrar5ETLWEvLV NXS4A+ddT/bS5KjBD02U+h6XmWag27bPWnhcUoMGMYJBvQ2zLyPK/6vuo0MD4gt8Ki0B dSnCUGUVgOnlXhlHPnXJp9bvGcdeSlzv4jCAmq2nLNhDnHaTrrg4AteQRDexcw4O/un8 O9WN+qHja2bez053/1wrbkZW67+0qMbdfUiYmVC56x2aRiW1Q77zzF6lZVnE/7Jrqc7f DYqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=3oTVAeENPmDaf9git57y6Kmww9iU2QL7J6grFOBmyQw=; b=lMAgXy2yRR02PvI0H8aVH8ZYJBo8A7p+KGm1ZoLgLyGFUMSccDDH+v2FzVHXeoNn2H UnvbLtyLc3mTiTULm8fWj7CT4OEj8Ng/4gXKyXTUgIPzKMXzE1nkjA7RkpMRRieWjPLj 9omTIKdRZCkCAJ/CLsEabssXB6BvqQyGdJyRg6zgATaJcI9MZH7pvpwCokgPJQTmfqNU Q86zNgIMise3/cXVaLoZ4fYq5+cWcazH02vYMt5Vpb5ZaoEtwQnaemFMCs3XBAuDcEJR mVWYKIVF9SR8wnagTXf4CnjDBi2hq+qkAyUbkMRmpBBZ3WJaflPi0eoqNrvl1YVZcR06 ZsFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h21-20020a056402281500b0043bfb069e20si3776246ede.458.2022.07.29.06.51.55; Fri, 29 Jul 2022 06:52:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236595AbiG2NNl (ORCPT + 99 others); Fri, 29 Jul 2022 09:13:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236732AbiG2NNS (ORCPT ); Fri, 29 Jul 2022 09:13:18 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D381B56BB6 for ; Fri, 29 Jul 2022 06:12:52 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 8D88868AA6; Fri, 29 Jul 2022 15:12:48 +0200 (CEST) Date: Fri, 29 Jul 2022 15:12:48 +0200 From: Christoph Hellwig To: Lyude Paul Cc: nouveau@lists.freedesktop.org, Christoph Hellwig , Ben Skeggs , Karol Herbst , David Airlie , Daniel Vetter , "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" , open list Subject: Re: [RFC] drm/nouveau/ttm: Stop calling into swiotlb Message-ID: <20220729131248.GA27137@lst.de> References: <20220728220545.163763-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220728220545.163763-1-lyude@redhat.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lyude, and thanks for taking a look. > -#if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86) > - need_swiotlb = is_swiotlb_active(dev->dev); > -#endif > - > ret = ttm_device_init(&drm->ttm.bdev, &nouveau_bo_driver, drm->dev->dev, > - dev->anon_inode->i_mapping, > - dev->vma_offset_manager, need_swiotlb, > - drm->client.mmu.dmabits <= 32); > + dev->anon_inode->i_mapping, > + dev->vma_offset_manager, > + nouveau_drm_use_coherent_gpu_mapping(drm), > + drm->client.mmu.dmabits <= 32); This will break setups for two reasons: - swiotlb is not only used to do device addressing limitations, so this will not catch the case of interconnect addressing limitations or forced bounce buffering which used used e.g. in secure VMs. - we might need bouncing for any DMA address below the physical address limit of the CPU But more fundamentally the use_dma32 argument to ttm_device_init is rather broken, as the onlyway to get a memory allocation that fits the DMA addressing needs of a device is to use the proper DMA mapping helpers. i.e. ttm_pool_alloc_page really needs to use dma_alloc_pages instead of alloc_pages as a first step. That way all users of the TTM pool will always get dma addressable pages and there is no need to guess the addressing limitations. The use_dma_alloc is then only needed for users that require coherent memory and are willing to deal with the limitations that this entails (e.g. no way to get at the page struct). > if (ret) { > NV_ERROR(drm, "error initialising bo driver, %d\n", ret); > return ret; > -- > 2.35.3 ---end quoted text---