linux-kernel - Re: [git pull] drm for 5.8-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d1ad025-e215-da23-5282-bbaf154fa979@amd.com>
Date:   Thu, 4 Jun 2020 10:10:21 +0200
From:   Christian König <christian.koenig@....com>
To:     Jason Gunthorpe <jgg@...lanox.com>,
        Dave Airlie <airlied@...il.com>,
        Christoph Hellwig <hch@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Logan Gunthorpe <logang@...tatee.com>
Subject: Re: [git pull] drm for 5.8-rc1

Am 03.06.20 um 22:13 schrieb Jason Gunthorpe:
> On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote:
>> Hi Linus,
>>
>> This is the main drm pull request for 5.8-rc1.
>>
>> Highlights:
>> Core DRM had a lot of refactoring around managed drm resources to make
>> drivers simpler.
>> Intel Tigerlake support is on by default
>> amdgpu now support p2p PCI buffer sharing and encrypted GPU memory
> Christoph Hellwig basically NAK'd this approach, why is it getting
> merged all of a sudden??

Dave and Daniel explicitly said they want to have this and it is ok as 
long as I open code it in the driver and keep it AMD internal.

We have that in discussion for years now and constructing/using the sg 
table is actually only the very minor piece of it. On the other hand 
there is a lot of work underway to get rid of abusing the sg tables as well.

>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fintel-gfx%2F20200311152838.GA24280%40infradead.org%2F&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C55b238b9104d4a8d4feb08d807faa11c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637268120315706063&amp;sdata=AgVJ45%2Ft%2FVYkyIGIGgMrop69XLQReLDpF0ahL5rjEjo%3D&amp;reserved=0
>
> Are we now OK with this same approach open coded in a driver?

Intel is apparently doing this as well for years, see the i915 driver 
internals.

> This wasn't Cc'd to the usual people doing work in this PCI P2P area??

I certainly prefer a common framework for this, but when my upstream 
maintainer says he wants to take this who am I to object?

Christian.

>
> See
>
> commit f44ffd677fb3562ac0a1ff9c8ae52672be741f00
> Author: Christian König <christian.koenig@....com>
> Date:   Fri Mar 23 16:56:37 2018 +0100
>
>      drm/amdgpu: add support for exporting VRAM using DMA-buf v3
>      
>      We should be able to do this now after checking all the prerequisites.
>      
>      v2: fix entrie count in the sgt
>      v3: manually construct the sg
>      
>      Signed-off-by: Christian König <christian.koenig@....com>
>      Acked-by: Daniel Vetter <daniel.vetter@...ll.ch>
>      Acked-by: Sumit Semwal <sumit.semwal@...aro.org>
>      Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F359295&amp;data=02%7C01%7Cchristian.koenig%40amd.com%7C55b238b9104d4a8d4feb08d807faa11c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637268120315706063&amp;sdata=YzNvxBVOf5hcUm5KjOzzV%2FcHG5jdGEYmrI76PQN9v3U%3D&amp;reserved=0
>
> [..]
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 82a3299e53c042..128a667ed8fa0d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -22,6 +22,7 @@
>    * Authors: Christian König
>    */
>   
> +#include <linux/dma-mapping.h>
>   #include "amdgpu.h"
>   #include "amdgpu_vm.h"
>   #include "amdgpu_atomfirmware.h"
> @@ -458,6 +459,104 @@ static void amdgpu_vram_mgr_del(struct ttm_mem_type_manager *man,
>   	mem->mm_node = NULL;
>   }
>   
> +/**
> + * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
> + *
> + * @adev: amdgpu device pointer
> + * @mem: TTM memory object
> + * @dev: the other device
> + * @dir: dma direction
> + * @sgt: resulting sg table
> + *
> + * Allocate and fill a sg table from a VRAM allocation.
> + */
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> +			      struct ttm_mem_reg *mem,
> +			      struct device *dev,
> +			      enum dma_data_direction dir,
> +			      struct sg_table **sgt)
> +{
> +	struct drm_mm_node *node;
> +	struct scatterlist *sg;
> +	int num_entries = 0;
> +	unsigned int pages;
> +	int i, r;
> +
> +	*sgt = kmalloc(sizeof(*sg), GFP_KERNEL);
> +	if (!*sgt)
> +		return -ENOMEM;
> +
> +	for (pages = mem->num_pages, node = mem->mm_node;
> +	     pages; pages -= node->size, ++node)
> +		++num_entries;
> +
> +	r = sg_alloc_table(*sgt, num_entries, GFP_KERNEL);
> +	if (r)
> +		goto error_free;
> +
> +	for_each_sg((*sgt)->sgl, sg, num_entries, i)
> +		sg->length = 0;
> +
> +	node = mem->mm_node;
> +	for_each_sg((*sgt)->sgl, sg, num_entries, i) {
> +		phys_addr_t phys = (node->start << PAGE_SHIFT) +
> +			adev->gmc.aper_base;
> +		size_t size = node->size << PAGE_SHIFT;
> +		dma_addr_t addr;
> +
> +		++node;
> +		addr = dma_map_resource(dev, phys, size, dir,
> +					DMA_ATTR_SKIP_CPU_SYNC);
> +		r = dma_mapping_error(dev, addr);
> +		if (r)
> +			goto error_unmap;
> +
> +		sg_set_page(sg, NULL, size, 0);
> +		sg_dma_address(sg) = addr;
> +		sg_dma_len(sg) = size;
>                  ^^^^^^^^^^^^^^
>    
> Jason