[PATCH] drm/amdgpu: Fix default page access routing

Jay Cornwall jay at jcornwall.me
Fri Nov 6 06:40:19 PST 2015


On 2015-11-06 02:28, Christian König wrote:
> On 05.11.2015 20:06, Jay Cornwall wrote:
>> The VM default page (used when a VM translation fails) is allocated in
>> system memory. The VM is misconfigured to interpret the physical 
>> address
>> as referencing a VRAM physical page.
>> 
>> Route default page accesses to system memory.
>> 
>> Signed-off-by: Jay Cornwall <jay at jcornwall.me>
>> Cc: <stable at vger.kernel.org> # v4.2+
> 
> Nice catch, patch is Reviewed-by: Christian König 
> <christian.koenig at amd.com>
> 
> Do we also need this for Radeon?

It looks like this field was introduced in CIK. This change could be 
replicated in radeon on those parts, but I haven't got one to test with.

I'm not sure if this misconfiguration is fatal. The default page should 
be used for loads only. I haven't been able to get anything besides 0 
from a faulting load on my Fiji with a system or VRAM default page. A 
physical address > VRAM doesn't seem to cause problems, either.

My primary motivation for this change is to allow HSA to handle faulting 
atomic operations. The KFD exposes a MTYPE=UC aperture to the user which 
allows atomics to be forwarded to system memory, via MC/BIF/PCI. When 
one of these atomic operations faults the MC is unable to handle the 
VRAM atomic (atomics are implemented by TC) and the TC hangs waiting for 
a response.

If the default page is directed towards BIF then the atomic is correctly 
discarded.

-- 
Jay Cornwall


More information about the dri-devel mailing list