linux-kernel - Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <2dff4d81-9b45-4d69-9e30-972f2c9318d9@app.fastmail.com>
Date:   Tue, 04 Jul 2023 17:24:49 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     Christian König <christian.koenig@....com>,
        "Arnd Bergmann" <arnd@...nel.org>,
        "Alex Deucher" <alexander.deucher@....com>,
        "Pan, Xinhui" <Xinhui.Pan@....com>,
        "Dave Airlie" <airlied@...il.com>,
        "Daniel Vetter" <daniel@...ll.ch>
Cc:     "Hawking Zhang" <Hawking.Zhang@....com>,
        "Lijo Lazar" <lijo.lazar@....com>,
        "Mario Limonciello" <mario.limonciello@....com>,
        "YiPeng Chai" <YiPeng.Chai@....com>, "Le Ma" <le.ma@....com>,
        "Bokun Zhang" <Bokun.Zhang@....com>,
        "Srinivasan Shanmugam" <srinivasan.shanmugam@....com>,
        "Shiwu Zhang" <shiwu.zhang@....com>, amd-gfx@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/amdgpu: avoid integer overflow warning in
 amdgpu_device_resize_fb_bar()

On Tue, Jul 4, 2023, at 16:51, Christian König wrote:
> Am 04.07.23 um 16:31 schrieb Arnd Bergmann:
>> On Tue, Jul 4, 2023, at 14:33, Christian König wrote:
>>>
>>> Modern AMD GPUs have 16GiB of local memory (VRAM), making those
>>> accessible to a CPU which can only handle 32bit addresses by resizing
>>> the BAR is impossible to begin with.
>>>
>>> But going a step further even without resizing it is pretty hard to get
>>> 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.
>
> Yeah, those are unfortunately very well known to us :(
>
>> 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?
>
> We have tons of x86 systems where we can't resize the BAR (because of 
> lack of BIOS setup of the root PCIe windows). So bank switching is still 
> perfectly supported.

Ok, good.

> After investigating (which sometimes even includes involving engineers 
> from ARM) we usually find that those boards doesn't even remotely comply 
> to the PCIe specification, both regarding power as well as functional 
> things like DMA coherency.

Makes sense, the power usage is clearly going to make this
impossible on a lot of boards. I would have expected noncoherent
DMA to be a solvable problem, since that generally works with
all drivers that use the dma-mapping interfaces correctly,
but I understand that drivers/gpu/* often does its own thing
here, which may make that harder.

     Arnd