AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Paneer Selvam, Arunpravin" <arunpravin.paneerselvam@amd.com>
To: John Olender <john.olender@gmail.com>,
	Alex Deucher <alexdeucher@gmail.com>,
	Christian Koenig <christian.koenig@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [RFC PATCH 1/2] drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram
Date: Mon, 12 May 2025 02:03:28 +0530	[thread overview]
Message-ID: <fbf53dc5-01f0-496c-88b0-86eada7c5a91@amd.com> (raw)
In-Reply-To: <70f66e11-7baa-4aed-ac88-f823305001e3@amd.com>



On 5/3/2025 5:53 PM, Paneer Selvam, Arunpravin wrote:
>
>
> On 5/2/2025 9:02 PM, John Olender wrote:
>> On 4/30/25 5:44 PM, Paneer Selvam, Arunpravin wrote:
>>>
>>> On 5/1/2025 2:50 AM, Alex Deucher wrote:
>>>> + Christian
>>>>
>>>> On Tue, Apr 29, 2025 at 7:24 AM John Olender <john.olender@gmail.com>
>>>> wrote:
>>>>> The drm_mm allocator tolerated being passed end > mm->size, but the
>>>>> drm_buddy allocator does not.
>>>>>
>>>>> Restore the pre-buddy-allocator behavior of allowing such placements.
>>>>>
>>>>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3448
>>>>> Signed-off-by: John Olender <john.olender@gmail.com>
>>>> This looks correct to me.
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>> I was thinking that we should return an error when lpfn > man->size.
>>>
>>> Regards,
>>> Arun.
>> This patch restores the previous behavior in the spirit of "Do not crash
>> the kernel".  The existing uvd placements are pretty clear in their
>> intent and were accepted until the switch to drm_buddy.  I think it's
>> fair to consider their style as expected.
>>
>> With that in mind, I'm not sure amdgpu_vram_mgr is the place this change
>> really belongs.  That is, I think it's worth asking:
>>
>> 1) Why does drm_mm accept end > mm->size without complaint?
>> 2) Why doesn't drm_buddy do the same?
>
> I remember that during the development of DRM buddy , we had a 
> discussion with Intel folks and decided to
> return an error in DRM buddy when end > mm->size. This was done to 
> ensure that, at the driver level,  lpfn
> has the correct value.
>
> I will modify this at drm_buddy to match with drm_mm and send the patch.
After giving it some thought, I think it is more effective to implement 
this tolerance at the VRAM manager level
and allow the DRM buddy manager to perform a strict validation, as this 
is necessary for other graphics drivers
(e.g., i915).

Regards,
Arun.
>
> Regards,
> Arun.
>>
>> Thanks,
>> John
>>
>>>>> ---
>>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/
>>>>> gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>>>> index 2d7f82e98df9..abdc52b0895a 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
>>>>> @@ -463,7 +463,7 @@ static int amdgpu_vram_mgr_new(struct
>>>>> ttm_resource_manager *man,
>>>>>           int r;
>>>>>
>>>>>           lpfn = (u64)place->lpfn << PAGE_SHIFT;
>>>>> -       if (!lpfn)
>>>>> +       if (!lpfn || lpfn > man->size)
>>>>>                   lpfn = man->size;
>>>>>
>>>>>           fpfn = (u64)place->fpfn << PAGE_SHIFT;
>>>>> -- 
>>>>> 2.47.2
>>>>>
>


  reply	other threads:[~2025-05-11 20:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29 11:24 [RFC PATCH 0/2] drm/amdgpu: CIK UVD initialization fixes John Olender
2025-04-29 11:24 ` [RFC PATCH 1/2] drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram John Olender
2025-04-30 21:20   ` Alex Deucher
2025-04-30 21:44     ` Paneer Selvam, Arunpravin
2025-05-02 15:32       ` John Olender
2025-05-03 12:23         ` Paneer Selvam, Arunpravin
2025-05-11 20:33           ` Paneer Selvam, Arunpravin [this message]
2025-05-11 20:37             ` Paneer Selvam, Arunpravin
2025-05-12  7:09               ` Christian König
2025-05-12  7:11                 ` Paneer Selvam, Arunpravin
2025-05-15 15:49                   ` Paneer Selvam, Arunpravin
2025-05-23 11:31                     ` Paneer Selvam, Arunpravin
2025-05-02  8:28     ` Christian König
2025-04-29 11:24 ` [RFC PATCH 2/2] drm/amdgpu/uvd: Ensure vcpu bos are within the uvd segment John Olender
2025-04-30 21:39   ` Alex Deucher
2025-05-02  8:36     ` Christian König
2025-05-03 20:31       ` John Olender
2025-05-05  9:02         ` Christian König
2025-05-05 16:06           ` John Olender
2025-05-07 11:31             ` John Olender
2025-05-29 23:15               ` John Olender
2025-06-02 10:00                 ` Christian König
2025-06-02 13:03                   ` John Olender
2025-06-03 14:34                     ` John Olender
2025-06-03 16:26                       ` Christian König
2025-06-03 17:52                         ` John Olender
2025-06-05  9:21       ` John Olender
2025-06-05  9:54         ` Christian König

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=fbf53dc5-01f0-496c-88b0-86eada7c5a91@amd.com \
    --to=arunpravin.paneerselvam@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=john.olender@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox