Re: [PATCH] drm/radeon: allocate dummy_page without DMA32 on fail

[Christian König]

Hi Anirudh,

On 7/16/26 04:08, Anirudh Srinivasan wrote:
> Hi Christian,
> 
> On Wed, Jul 15, 2026 at 4:15 AM Christian König
> <christian.koenig@xxxxxxx> wrote:
>>
>> On 7/14/26 18:03, Anirudh Srinivasan wrote:
>>> radeon fails to probe on platforms that have all their memory above the
>>> 32-bit range with an -ENOMEM because dummy_page_init calls
>>> alloc_page(GFP_DMA32), which would fail.
>>
>> Unfortunately I clearly have to reject this.
>>
>> The DMA32 allocation is mandatory for radeon to work correctly on some platforms.
>>
>>> Allow this driver to work on such platforms by falling back to
>>> ZONE_NORMAL regions. dma_map_page called subsequently would catch any
>>> issues with the device being unable to DMA into the mapped page.
>>
>> No, it doesn't.
>>
>> It's just your special case that dma_map_page() is able to use some IOMMU to remap the page below 32bits so that the driver can access it.
>>
>> The problem is that we have quite a bunch of cases where this doesn't work correctly and eventually result in all kinds of trouble, including random memory corruptions.
>>
>> In those cases it's better to not load the driver at all than to later deal with corrupted data.
> 
> So this platform has an IOMMU, but it isn't enabled in the upstream
> kernel at the moment. I am able to boot up to framebuffer console.

That is not even remotely enough to actually test the driver.

What happens is that you allocation succeeds, but you simply doesn't exercise the functionality which would need the dummy page.

> Is there anything that isn't expected to work in this setup? Is there
> some test I can run to verify this?

For the technical background, the dummy page is there to prevent buggy applications/driver code to crash the system.

The general idea is that a reads/writes which otherwise would go into nirvana are redirected to the dummy page and so prevented from harming the system as a whole.

The problem is that while some HW generations can handle 40bit of PCI addresses the dummy page register is only 32bit wide in some cases (I would need to double check your specific HW generation, maybe that would help).

To actually make sure everything works as expected you need to enable some desktop system and run OpenGL tests. If then an error occurs and IOMMU confirms that the right address is used for the dummy write then we could be save that this actually works.

> I should look into whether the IOMMU on this cihp can be enabled and
> then try this out too.

Well enabling IOMMU could eventually help, but the code in the current form would still fail. You need to use something like dma_alloc_coherent() and I think that this won't work because of the HW restrictions.

>>
>> What could be possible is to add a special quirk for your platform to not allocate the dummy page as DMA32 in the first place.
> 
> So some kind of a whitelisted set of PCIE vendor/ID combos (with
> working IOMMUS?) where we fallback to non DMA32 ranges?

No, what you are testing here is basically that display is functional and not anything else.

Regards,
Christian.

> 
> Regards
> Anirudh Srinivasan