On 20/11/17 02:20 PM, Christian König wrote:
> Am 20.11.2017 um 11:36 schrieb Michel Dänzer:
>> On 18/11/17 03:31 PM, Christian König wrote:
>>> Am 17.11.2017 um 17:09 schrieb Michel Dänzer:
>>>> On 17/11/17 11:28 AM, Christian König wrote:
>>>>> Ping? Michel, Alex can somebody take a look?
>>>> Patch 2 is
>>>>
>>>> Reviewed-by: Michel Dänzer <michel.daenzer at amd.com>
>>>>
>>>>
>>>> With patches 1 & 3, it's not 100% clear to me what the idea is behind
>>>> the handling of the hole on the kernel and userspace side. Maybe you
>>>> can
>>>> add some explanation in code comments or the commit logs?
>>> Yeah, that is actually a bit of a mess because the hardware
>>> documentation wasn't very clear on how this works.
>>>
>>> How about this as extra code comment on patch 1 to the assignment of
>>> dev_info.virtual_address_max:
>>>
>>> /*
>>> Â Â * Old userspace isn't aware of the VA hole on Vega10. So in theory an
>>> client could get invalid VA addresses assigned.
>>> Â Â * To fix this and keep backward compatibility we limit the VA space
>>> reported in this field to the range below the hole.
>>> Â Â */
>>>
>>> The last patch is then to report the VA space above the hole, cause that
>>> is actually what libdrm should use.
>>>
>>> The crux is when I put the VA space above the hole directly into the old
>>> fields older versions of libdrm would break and we can't do that.
>> That much was actually clear. :) Maybe some questions will expose what
>> I'm missing:
>>
>>
>> Patch 1:
>>
>>> @@ -880,14 +880,14 @@Â static int amdgpu_cs_ib_vm_chunk(struct
>>> amdgpu_device *adev,
>>> Â Â Â Â Â Â Â Â Â Â Â Â Â if (chunk->chunk_id != AMDGPU_CHUNK_ID_IB)
>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>> Â -Â Â Â Â Â Â Â Â Â Â Â r = amdgpu_cs_find_mapping(p, chunk_ib->va_start,
>>> -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â &aobj, &m);
>>> +Â Â Â Â Â Â Â Â Â Â Â va_start = chunk_ib->va_start & AMDGPU_VA_HOLE_MASK;
>>> +Â Â Â Â Â Â Â Â Â Â Â r = amdgpu_cs_find_mapping(p, va_start, &aobj, &m);
>> I don't understand how userspace can make use of the address space above
>> the hole, since AMDGPU_VA_HOLE_MASK is 0x0000ffffffffffffULL and
>> AMDGPU_VA_HOLE_END is 0xffff800000000000ULL, so masking with
>> AMDGPU_VA_HOLE_MASK always results in an address below or inside the
>> hole?
>
> Yes, and exactly that is intended here.
>
> See for programming the MC and filling the page tables you handle this
> as if there isn't a hole in the address space.
>
> Only when you start to use the address from userspace you will find that
> you need to sign extend bit 47 into bits 48-63.
>
> Applying the AMDGPU_VA_HOLE_MASK to and address masks out the upper 16
> bits and so removes the sign extension again.
>
>>
>>
>>> @@ -566,6 +566,17 @@Â int amdgpu_gem_va_ioctl(struct drm_device *dev,
>>> void *data,
>>> Â Â Â Â Â Â Â Â Â return -EINVAL;
>>> Â Â Â Â Â }
>>> Â +Â Â Â if (args->va_address >= AMDGPU_VA_HOLE_START &&
>>> +Â Â Â Â Â Â Â args->va_address < AMDGPU_VA_HOLE_END) {
>>> +Â Â Â Â Â Â Â dev_dbg(&dev->pdev->dev,
>>> +Â Â Â Â Â Â Â Â Â Â Â "va_address 0x%LX is in VA hole 0x%LX-0x%LX\n",
>>> +Â Â Â Â Â Â Â Â Â Â Â args->va_address, AMDGPU_VA_HOLE_START,
>>> +Â Â Â Â Â Â Â Â Â Â Â AMDGPU_VA_HOLE_END);
>>> +Â Â Â Â Â Â Â return -EINVAL;
>>> +Â Â Â }
>>> +
>>> +Â Â Â args->va_address &= AMDGPU_VA_HOLE_MASK;
>> Ignoring the above, I think the masking with AMDGPU_VA_HOLE_MASK would
>> need to be done before checking for the hole, otherwise the masked
>> address could be inside the hole?
>
> The masking just removes the sign extension which created the hole in
> the first place.
>
> The VM and MC is programmed as if there isn't a hole.
>
>> Patch 3:
>>
>>> @@ -577,10 +578,17 @@Â static int amdgpu_info_ioctl(struct drm_device
>>> *dev, void *data, struct drm_file
>>> Â Â Â Â Â Â Â Â Â Â Â Â Â dev_info.ids_flags |= AMDGPU_IDS_FLAGS_FUSION;
>>> Â Â Â Â Â Â Â Â Â if (amdgpu_sriov_vf(adev))
>>> Â Â Â Â Â Â Â Â Â Â Â Â Â dev_info.ids_flags |= AMDGPU_IDS_FLAGS_PREEMPTION;
>>> +
>>> +Â Â Â Â Â Â Â vm_size = adev->vm_manager.max_pfn * AMDGPU_GPU_PAGE_SIZE;
>>> Â Â Â Â Â Â Â Â Â dev_info.virtual_address_offset = AMDGPU_VA_RESERVED_SIZE;
>>> Â Â Â Â Â Â Â Â Â dev_info.virtual_address_max =
>>> -Â Â Â Â Â Â Â Â Â Â Â min(adev->vm_manager.max_pfn * AMDGPU_GPU_PAGE_SIZE,
>>> -Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â AMDGPU_VA_HOLE_START);
>>> +Â Â Â Â Â Â Â Â Â Â Â min(vm_size, AMDGPU_VA_HOLE_START);
>>> +
>>> +Â Â Â Â Â Â Â vm_size -= AMDGPU_VA_RESERVED_SIZE;
>>> +Â Â Â Â Â Â Â if (vm_size > AMDGPU_VA_HOLE_START) {
>>> +Â Â Â Â Â Â Â Â Â Â Â dev_info.high_va_offset = AMDGPU_VA_HOLE_END;
>>> +Â Â Â Â Â Â Â Â Â Â Â dev_info.high_va_max = AMDGPU_VA_HOLE_END | vm_size;
>>> +Â Â Â Â Â Â Â }
>> This mostly makes sense, except for the
>>
>> Â Â Â Â Â Â Â dev_info.high_va_max = AMDGPU_VA_HOLE_END | vm_size;
>>
>> line. Can you explain how simply or'ing together the address of the end
>> of the hole and the VM size works correctly in all cases?
>>
>> As an extreme example, with vm_size == 1, this value would compute as
>> 0xffff800000000001ULL, which seems wrong or at least weird.
>
> We check above if vm_size is larger than AMDGPU_VA_HOLE_START, in other
> words larger than 0x8000000000.
>
> Since vm_size is once more in the value range the MC expects it (without
> the hole) that should give us the right result to sign extend bit 47
> into bits 48-63, e.g. 0xffff800000000.
>
>
> And yes that initially confused me as well. Especially that you need to
> program the MC and fill the page tables as if there wouldn't be a hole
> in the address space.
>
> Applying "& AMDGPU_VA_HOLE_MASK" and "| AMDGPU_VA_HOLE_END" just
> converts between the representation with and without the hole in it.
Thanks for the explanation, I get it now.
For the benefit of future readers of this code, it would be nice to have
a short version of this explanation as a comment, e.g. above the
AMDGPU_VA_HOLE_* defines.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
