[PATCH 01/10] drm/amdgpu: use only the lower address space on GMC9

Xiao, Jack Jack.Xiao at amd.com
Thu Aug 30 03:48:43 UTC 2018


Can you explain what the benefits can be gained from AGP aperture enablement? Otherwise, it would increase our maintenance workload.

Regards,
Jack

-----Original Message-----
From: Christian König <ckoenig.leichtzumerken at gmail.com> 
Sent: Wednesday, August 29, 2018 4:47 PM
To: Kuehling, Felix <Felix.Kuehling at amd.com>; Koenig, Christian <Christian.Koenig at amd.com>; Xiao, Jack <Jack.Xiao at amd.com>; amd-gfx at lists.freedesktop.org
Subject: Re: [PATCH 01/10] drm/amdgpu: use only the lower address space on GMC9

Completely agree with Felix here.

It makes system memory access slightly simpler, but I would say that you accidentally corrupt the GART table and that you accidentally corrupt the the AGP aperture is equally likely.

Regards,
Christian.

Am 28.08.2018 um 20:12 schrieb Felix Kuehling:
> The GPU always has access to the entire guest physical address space.
> You can just program arbitrary addresses into page table entries and 
> set the system bit. That's how GART and GPUVM mappings work. They will 
> not go through the AGP aperture. And there is no mechanism (other than 
> an
> IOMMU) to protect system memory from GPU access.
>
> Regards,
>    Felix
>
>
> On 2018-08-28 07:41 AM, Christian König wrote:
>> Well that is indeed true, but we still have IOMMU between the GPU and 
>> the system memory.
>>
>> So we should still catch issues when something goes terrible wrong.
>>
>> Additional to that only the system domain, e.g. kernel copies, page 
>> table updates etc are allowed to use it.
>>
>> Regards,
>> Christian.
>>
>> Am 28.08.2018 um 09:06 schrieb Xiao, Jack:
>>> I mean it has risk to make GPU allowed to access to most system 
>>> memory without explicit claiming, it's easier to mask problem.
>>>
>>> Regards,
>>> Jack
>>>
>>> -----Original Message-----
>>> From: Koenig, Christian
>>> Sent: Tuesday, August 28, 2018 2:46 PM
>>> To: Xiao, Jack <Jack.Xiao at amd.com>; Kuehling, Felix 
>>> <Felix.Kuehling at amd.com>; Christian König 
>>> <ckoenig.leichtzumerken at gmail.com>; amd-gfx at lists.freedesktop.org
>>> Subject: Re: [PATCH 01/10] drm/amdgpu: use only the lower address 
>>> space on GMC9
>>>
>>>> This series patches seems to make AGP aperture allowed to access 
>>>> any system memory (16GB) bypass GPU VM protection.
>>> The system aperture should only be active in the system domain, or 
>>> otherwise applications would have access to local memory as well.
>>>
>>> There are some bits in the VM registers to enable/disable that, but 
>>> when we would have that setting incorrect we would see quite a bunch 
>>> of other problems.
>>>
>>> Might still be a good idea to double check if all the bits are setup 
>>> correctly.
>>>
>>> Regards,
>>> Christian.
>>>
>>> Am 28.08.2018 um 07:31 schrieb Xiao, Jack:
>>>> This series patches seems to make AGP aperture allowed to access 
>>>> any system memory (16GB) bypass GPU VM protection.
>>>> If someone made a wrong logic requesting an illegal address which 
>>>> occasionally was located inside AGP aperture, but without any VM 
>>>> protection, the illegal address would be finally translated into a 
>>>> system memory address; if GPU read/wrote such system memory 
>>>> address, the system memory address might belong to kernel or any 
>>>> user application, the r/w operation would result in any unpredictable issue.
>>>> The most important is that such kind of issue is so hard to be 
>>>> addressed.
>>>> Is it worth doing this, but exposing risk?
>>>>
>>>> Regards,
>>>> Jack
>>>>
>>>> -----Original Message-----
>>>> From: amd-gfx <amd-gfx-bounces at lists.freedesktop.org> On Behalf Of 
>>>> Felix Kuehling
>>>> Sent: Tuesday, August 28, 2018 3:03 AM
>>>> To: Christian König <ckoenig.leichtzumerken at gmail.com>;
>>>> amd-gfx at lists.freedesktop.org; Koenig, Christian 
>>>> <Christian.Koenig at amd.com>
>>>> Subject: Re: [PATCH 01/10] drm/amdgpu: use only the lower address 
>>>> space on GMC9
>>>>
>>>> The point of this series seems to be to allow access to small 
>>>> system memory BOs (one page) without a GART mapping. I'm guessing 
>>>> that reduces pressure on the GART and removes the need for HDP and 
>>>> TLB flushes. Why does Patch 10 only enable that on GFXv9? Is there 
>>>> less benefit on older chips?
>>>>
>>>> Is this related to your recent changes to allow page tables in 
>>>> system memory?
>>>>
>>>> See my replies to patch 6 and 8. Other than that, the series is
>>>> Acked-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>>>
>>>> Regards,
>>>>      Felix
>>>>
>>>>
>>>> On 2018-08-27 12:53 PM, Christian König wrote:
>>>>> Only use the lower address space on GMC9 for the system domain.
>>>>> Otherwise we would need to sign extend GMC addresses.
>>>>>
>>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>>> ---
>>>>>     drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++----
>>>>>     1 file changed, 3 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> index e44b5191735d..d982956c8329 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>>> @@ -938,11 +938,10 @@ static int gmc_v9_0_sw_init(void *handle)
>>>>>         if (r)
>>>>>             return r;
>>>>>     -    /* Set the internal MC address mask
>>>>> -     * This is the max address of the GPU's
>>>>> -     * internal address space.
>>>>> +    /* Use only the lower range for the internal MC address mask.
>>>>> This is
>>>>> +     * the max address of the GPU's internal address space.
>>>>>          */
>>>>> -    adev->gmc.mc_mask = 0xffffffffffffULL; /* 48 bit MC */
>>>>> +    adev->gmc.mc_mask = 0x7fffffffffffULL;
>>>>>            /* set DMA mask + need_dma32 flags.
>>>>>          * PCIE - can handle 44-bits.
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx



More information about the amd-gfx mailing list