[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