All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: "Liu, Monk" <Monk.Liu-5C7GfCeVMHo@public.gmane.org>,
	"Lou, Wentao" <Wentao.Lou-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Zhu, Rex" <Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
Cc: "Deng, Emily" <Emily.Deng-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH] drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START
Date: Thu, 17 Jan 2019 08:30:16 +0000	[thread overview]
Message-ID: <859dcf48-f4bf-d3ec-0893-369c7fad51ed@amd.com> (raw)
In-Reply-To: <CY4PR1201MB0245C5E3F6810C9157C9FDCF84830-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 9343 bytes --]

Hi Monk,

ok let me explain a bit more how the hardware works.

The GMC manages a virtual 64bit address space, but only 48bit of that virtual address space are handled by the page table walker.

The 48bits of address space are sign extended, so bit 47 of that are extended into bits 48-63.

This gives us the following memory layout:
0x0
.... virtual address space
0x8000 0000 0000
.... hole
0xFFFF 8000 0000 0000
.... virtual address space
0xFFFF FFFF FFFF FFFF

Trying to access the hole results in a range fault interrupt IIRC.

When doing the VM page table walk the topmost 16bits are ignored, so when programming the page table walker you cut those of and use a linear address again. This is what AMDGPU_GMC_HOLE_MASK is good for.

Now on Vega/Raven/Picasso etc.. (everything with a GFX9) the lower range (0x0-0x8000 0000 0000) is reserved for SVA/ATC use. Since we unfortunately didn't knew that initially we exposed those to older userspace as usable and also put the CSA in there.

The most likely cause of this is that we still have a bug somewhere about this, e.g. not correctly using sign extended addresses *OR* using sign extended addresses where we should use linear instead.

Regards,
Christian.

Am 17.01.19 um 09:04 schrieb Liu, Monk:
Hi Christian

I believe Wentao can fix the issue we it by below step:

  1.  Return Virtual_address_max (UMD use it) to HOLE_START – RESERVED_SIZE
  2.  [optional] Still Keep virtual_address_offset to RESERVED_SIZE (current way, I think it’s because previously we put CSA in 0 --> RESERVED_SIZE space)
  3.  Put CSA in HOLE_START – RESERVED_SIZE  ==> HOLE_START (it’s current design)

I don’t get where above scheme is not correct … can you give more explain for the GMC_HOLE_START ?

e.g.

  1.  why you set GMC_HOLE_START to 0x8’000’0000’0000 (half size of MAX of 48bit address space) ? is it for HSA purpose to make sure GPU address can also be used for CPU address ?
  2.  now MAX_PFN is 1’000’0000’0000, do you need to change GMC_HOLE_START ?

thanks
we need some catch up

/Monk

From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org><mailto:amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Koenig, Christian
Sent: Thursday, January 17, 2019 3:39 PM
To: Lou, Wentao <Wentao.Lou@amd.com><mailto:Wentao.Lou@amd.com>; Liu, Monk <Monk.Liu@amd.com><mailto:Monk.Liu@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Zhu, Rex <Rex.Zhu@amd.com><mailto:Rex.Zhu@amd.com>
Cc: Deng, Emily <Emily.Deng@amd.com><mailto:Emily.Deng@amd.com>
Subject: Re: [PATCH] drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START

Am 17.01.19 um 04:17 schrieb Lou, Wentao:
Hi Christian,

Your solution as:
addr = (max_pfn - (AMDGPU_VA_RESERVED_SIZE >> AMDGPU_PAGE_SHIFT)) << AMDGPU_PAGE_SHIFT;
now max_pfn = 0x10 0000 0000, AMDGPU_VA_RESERVED_SIZE = 0x10 0000, AMDGPU_PAGE_SHIFT = 12
Still got addr = 0xFFFF FFF0 0000, which would cause ring gfx timeout.

But 0xFFFF FFF0 0000 is the correct address, if that is causing a problem then there is a bug somewhere else.

Please try to use AMDGPU_GMC_HOLE_START-AMDGPU_VA_RESERVED_SIZE as well. Does that work?



Before commit 1bf621c42137926ac249af761c0190a9258aa0db, vm_size was 32GB, and csa_addr was under AMDGPU_GMC_HOLE_START.

Wait a second why was the vm_size 32GB? This is on a Vega10 isn't it?


I didn’t understand why csa_addr need to be above AMDGPU_GMC_HOLE_START now.

On Vega10 the lower range, e.g. everything below AMDGPU_GMC_HOLE_START is reserved for SVA.

Regards,
Christian.


Thanks.

BR,
Wentao



From: Koenig, Christian <Christian.Koenig@amd.com><mailto:Christian.Koenig@amd.com>
Sent: Wednesday, January 16, 2019 5:48 PM
To: Lou, Wentao <Wentao.Lou@amd.com><mailto:Wentao.Lou@amd.com>; Liu, Monk <Monk.Liu@amd.com><mailto:Monk.Liu@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Zhu, Rex <Rex.Zhu@amd.com><mailto:Rex.Zhu@amd.com>
Cc: Deng, Emily <Emily.Deng@amd.com><mailto:Emily.Deng@amd.com>
Subject: Re: [PATCH] drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START

Hi Wentao,

well the problem is you don't seem to understand how the hardware works.

See the engines see an MC address space with a hole in the middle, similar to the how x86 64bit CPU address space works. But the page tables are programmed linearly.

So the calculation in amdgpu_driver_open_kms() is correct because it takes the MC address and mages a linear page table index from it again.

The only thing we might need to fix here is shifting max_pfn before the subtraction and I doubt that even that is necessary.

Regards,
Christian.

Am 16.01.19 um 10:34 schrieb Lou, Wentao:

Hi Christian,



Now vm_size was set to 0x4 0000 GB by below commit:

1bf621c42137926ac249af761c0190a9258aa0db drm/amdgpu: Remove unnecessary VM size calculations



So that max_pfn would be 0x10 0000 0000.

amdgpu_csa_vaddr would make max_pfn << 12 to get 0x1 0000 0000 0000, and then minus AMDGPU_VA_RESERVED_SIZE, to get 0xFFFF FFF0 0000

unfortunately this number was between AMDGPU_GMC_HOLE_START and AMDGPU_GMC_HOLE_END, so that amdgpu_gmc_sign_extend was called to make it 0xFFFF FFFF FFF0 0000



in amdgpu_driver_open_kms, extended csa_addr cannot be passed into amdgpu_map_static_csa directly, it would be above the limit of max_pfn.

So that csa_addr was restricted by AMDGPU_GMC_HOLE_MASK to make it possible for amdgpu_vm_alloc_pts.

But this restriction by AMDGPU_GMC_HOLE_MASK would make the address fall back into AMDGPU_GMC_HOLE again,  which causing GPU reset.

We just put amdgpu_csa_vaddr back to AMDGPU_GMC_HOLE_START, to avoid the address touching AMDGPU_GMC_HOLE.

By the way, if max_pfn was shift much to the left, it would always get zero, with or without min(*,*).





BR,

Wentao







-----Original Message-----
From: Koenig, Christian <Christian.Koenig@amd.com><mailto:Christian.Koenig@amd.com>
Sent: Tuesday, January 15, 2019 4:02 PM
To: Liu, Monk <Monk.Liu@amd.com><mailto:Monk.Liu@amd.com>; Lou, Wentao <Wentao.Lou@amd.com><mailto:Wentao.Lou@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>; Zhu, Rex <Rex.Zhu@amd.com><mailto:Rex.Zhu@amd.com>
Subject: Re: [PATCH] drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START



Am 15.01.19 um 07:19 schrieb Liu, Monk:

> The max_pfn is now 1'0000'0000'0000'0000 (bytes) which is above 48 bit now, and it with AMDGPU_GMC_HOLE_MASK make it to zero ....

>

> And in code "amdgpu_driver_open_kms()" I saw @Zhu, Rex write the code as :

>

> "csa_addr = amdgpu_csa_vadr(adev) & AMDGPU_GMC_HOLE_MASK", I think this is wrong since you intentionally place the csa above GMC hole, right ?



The fix is just completely incorrect since min(adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT, AMDGPU_GMC_HOLE_START) still gives you 0 when we shift max_pfn to much to the left.



The correct solution is to substract the reserved size first and then shift. E.g.:



addr = (max_pfn - (AMDGPU_VA_RESERVED_SIZE >> AMDGPU_PAGE_SHIFT)) << AMDGPU_PAGE_SHIFT;



Regards,

Christian.



>

> Looks like  we should modify this place

>

> /Monk

>

> -----Original Message-----

> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org<mailto:amd-gfx-bounces@lists.freedesktop.org>> On Behalf Of

> Christian K?nig

> Sent: Monday, January 14, 2019 9:05 PM

> To: Lou, Wentao <Wentao.Lou@amd.com<mailto:Wentao.Lou@amd.com>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>

> Subject: Re: [PATCH] drm/amdgpu: csa_vaddr should not larger than

> AMDGPU_GMC_HOLE_START

>

> Am 14.01.19 um 09:40 schrieb wentalou:

>> After removing unnecessary VM size calculations, vm_manager.max_pfn

>> would reach 0x10,0000,0000 max_pfn << AMDGPU_GPU_PAGE_SHIFT exceeding

>> AMDGPU_GMC_HOLE_START would caused GPU reset.

>>

>> Change-Id: I47ad0be2b0bd9fb7490c4e1d7bb7bdacf71132cb

>> Signed-off-by: wentalou <Wentao.Lou@amd.com<mailto:Wentao.Lou@amd.com>>

> NAK, that is incorrect. We intentionally place the csa above the GMC hole.

>

> Regards,

> Christian.

>

>> ---

>>    drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 3 ++-

>>    1 file changed, 2 insertions(+), 1 deletion(-)

>>

>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c

>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c

>> index 7e22be7..dd3bd01 100644

>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c

>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c

>> @@ -26,7 +26,8 @@

>>

>>    uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev)

>>    {

>> -        uint64_t addr = adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT;

>> +       uint64_t addr = min(adev->vm_manager.max_pfn << AMDGPU_GPU_PAGE_SHIFT,

>> +                                                    AMDGPU_GMC_HOLE_START);

>>

>>          addr -= AMDGPU_VA_RESERVED_SIZE;

>>          addr = amdgpu_gmc_sign_extend(addr);

> _______________________________________________

> amd-gfx mailing list

> amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>

> https://lists.freedesktop.org/mailman/listinfo/amd-gfx






[-- Attachment #1.2: Type: text/html, Size: 24862 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2019-01-17  8:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14  8:40 [PATCH] drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START wentalou
     [not found] ` <1547455236-30130-1-git-send-email-Wentao.Lou-5C7GfCeVMHo@public.gmane.org>
2019-01-14  9:05   ` Liu, Monk
2019-01-14 13:05   ` Christian König
     [not found]     ` <37b395b0-8503-238f-8775-66eb8795d23f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-01-15  6:19       ` Liu, Monk
     [not found]         ` <CY4PR1201MB0245AB79C8C8319D8DFB3A3884810-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-15  8:02           ` Koenig, Christian
     [not found]             ` <7f3f7b71-7acc-689a-e1d8-6fb184771f7b-5C7GfCeVMHo@public.gmane.org>
2019-01-16  9:34               ` Lou, Wentao
     [not found]                 ` <BYAPR12MB2742181357E4D7DF7C171EE983820-ZGDeBxoHBPmbrehcvEBedAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-01-16  9:47                   ` Koenig, Christian
     [not found]                     ` <574d6ca8-f1c8-8ac0-3dbe-23aed7c0125d-5C7GfCeVMHo@public.gmane.org>
2019-01-17  3:17                       ` Lou, Wentao
     [not found]                         ` <BYAPR12MB27427158A5684A31BF96AB4783830-ZGDeBxoHBPmbrehcvEBedAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-01-17  7:39                           ` Koenig, Christian
     [not found]                             ` <361544e2-dd33-3b89-1211-4566b060b785-5C7GfCeVMHo@public.gmane.org>
2019-01-17  8:04                               ` Liu, Monk
     [not found]                                 ` <CY4PR1201MB0245C5E3F6810C9157C9FDCF84830-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-17  8:30                                   ` Koenig, Christian [this message]
     [not found]                                     ` <859dcf48-f4bf-d3ec-0893-369c7fad51ed-5C7GfCeVMHo@public.gmane.org>
2019-01-17 13:19                                       ` Liu, Monk
     [not found]                                         ` <CY4PR1201MB0245C8076917864AA97A0FFA84830-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-17 13:25                                           ` Koenig, Christian
     [not found]                                             ` <cf3489f5-deb2-85ef-844a-b4c050f71d29-5C7GfCeVMHo@public.gmane.org>
2019-01-18  1:32                                               ` Liu, Monk
     [not found]                                                 ` <CY4PR1201MB02457ECA700E3AE8B321AC90849C0-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-18  9:11                                                   ` Christian König
     [not found]                                                     ` <c83cd7ec-03a5-45c0-b497-d5a5ec838880-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-01-18  9:29                                                       ` Chunming Zhou
     [not found]                                                         ` <effb374a-9803-d451-41c4-991a2cd0aa9a-5C7GfCeVMHo@public.gmane.org>
2019-01-18 10:39                                                           ` Koenig, Christian
2019-01-18 10:57                                                       ` Liu, Monk
     [not found]                                                         ` <CY4PR1201MB0245D532D38DBA7F9BC445B9849C0-1iTaO6aE1DBfNQakwlCMTGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-18 12:20                                                           ` Koenig, Christian
     [not found]                                                             ` <eff1c302-1c8d-e358-077e-704b67c3bd41-5C7GfCeVMHo@public.gmane.org>
2019-01-21  4:35                                                               ` Liu, Monk
     [not found]                                                                 ` <DM5PR1201MB02516E33597C13BAA8C72299849F0-grEf7a3NxMClG5oLOQIDXGrFom/aUZj6nBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2019-01-21  9:55                                                                   ` Koenig, Christian
     [not found]                                                                     ` <c700df28-900c-f097-4ceb-0e6e8dcd35e8-5C7GfCeVMHo@public.gmane.org>
2019-01-29 22:33                                                                       ` Kuehling, Felix
2019-01-18  4:44                                       ` Lou, Wentao
     [not found]                                         ` <BYAPR12MB274227E7B0D66F840747EB3C839C0-ZGDeBxoHBPmbrehcvEBedAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-01-18  9:01                                           ` Koenig, Christian
     [not found]                                             ` <b5d15c16-a023-3fb0-d5e3-b12276b6fc04-5C7GfCeVMHo@public.gmane.org>
2019-01-18 11:07                                               ` Liu, Monk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=859dcf48-f4bf-d3ec-0893-369c7fad51ed@amd.com \
    --to=christian.koenig-5c7gfcevmho@public.gmane.org \
    --cc=Emily.Deng-5C7GfCeVMHo@public.gmane.org \
    --cc=Monk.Liu-5C7GfCeVMHo@public.gmane.org \
    --cc=Rex.Zhu-5C7GfCeVMHo@public.gmane.org \
    --cc=Wentao.Lou-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.