Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-527-gee7b8d90aa-fm-20230629.001-gee7b8d90
Mime-Version: 1.0
Message-Id: <9b03246d-b46e-4b91-968a-e9ffc2fc26db@app.fastmail.com>
In-Reply-To: <f1b190cb-3af7-178b-baeb-b59363868779@amd.com>
References: <20230703123557.3355657-1-arnd@kernel.org>
 <f4bc3739-3ff1-6fa7-5d7d-890f451315bf@amd.com>
 <788147c6-defd-496a-8174-1571b73d1a71@app.fastmail.com>
 <f1b190cb-3af7-178b-baeb-b59363868779@amd.com>
Date:   Tue, 04 Jul 2023 16:31:25 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        "Arnd Bergmann" <arnd@kernel.org>,
        "Alex Deucher" <alexander.deucher@amd.com>,
        "Pan, Xinhui" <Xinhui.Pan@amd.com>,
        "Dave Airlie" <airlied@gmail.com>,
        "Daniel Vetter" <daniel@ffwll.ch>
Cc:     "Hawking Zhang" <Hawking.Zhang@amd.com>,
        "Lijo Lazar" <lijo.lazar@amd.com>,
        "Mario Limonciello" <mario.limonciello@amd.com>,
        "YiPeng Chai" <YiPeng.Chai@amd.com>, "Le Ma" <le.ma@amd.com>,
        "Bokun Zhang" <Bokun.Zhang@amd.com>,
        "Srinivasan Shanmugam" <srinivasan.shanmugam@amd.com>,
        "Shiwu Zhang" <shiwu.zhang@amd.com>, amd-gfx@lists.freedesktop.org,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/amdgpu: avoid integer overflow warning in
 amdgpu_device_resize_fb_bar()
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jul 4, 2023, at 14:33, Christian K=C3=B6nig wrote:
> Am 04.07.23 um 14:24 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 08:54, Christian K=C3=B6nig wrote:
>>> Am 03.07.23 um 14:35 schrieb Arnd Bergmann:
>> Not sure I understand the specific requirement. Do you mean the entire
>> amdgpu driver requires 64-bit BAR addressing, or just the bits that
>> resize the BARs?
>
> Well a bit of both.
>
> Modern AMD GPUs have 16GiB of local memory (VRAM), making those=20
> accessible to a CPU which can only handle 32bit addresses by resizing=20
> the BAR is impossible to begin with.
>
> But going a step further even without resizing it is pretty hard to ge=
t=20
> that hardware working on such an architecture.

I'd still like to understand this part better, as we have a lot of
arm64 chips with somewhat flawed PCIe implementations, often with
a tiny 64-bit memory space, but otherwise probably capable of
using a GPU.

What exactly do you expect to happen here?

a) Use only part of the VRAM but otherwise work as expected
b) Access all of the VRAM, but at a performance cost for
   bank switching?
c) Require kernel changes to make a) or b) work, otherwise
   fail to load
d) have no chance of working even with driver changes

>>> It might be cleaner to just not build the whole driver on such syste=
ms
>>> or at least leave out this function.
>> How about this version? This also addresses the build failure, but
>> I don't know if this makes any sense:
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -1325,6 +1325,9 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_d=
evice *adev)
>>          u16 cmd;
>>          int r;
>>  =20
>> +       if (!IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
>> +               return 0;
>> +
>
> Yes, if that suppresses the warning as well then that makes perfect=20
> sense to me.

Ok, I'll send that as a v2 then.

    Arnd