On Fri, May 23, 2025 at 09:15:21AM -0700, mhkelle...@gmail.com wrote:
> Commit 37b4837959cb ("video: deferred io with physically contiguous
> memory") from the year 2008 purported to add support for contiguous
> kernel memory framebuffers. The motivating device, sh_mobile_lcdcfb, uses
> dma_alloc_coherent() to allocate framebuffer memory, which is likely to
> use alloc_pages(). It's unclear to me how this commit actually worked at
> the time, unless dma_alloc_coherent() was pulling from a CMA pool instead
> of alloc_pages(). Or perhaps alloc_pages() worked differently or on the
> arm32 architecture on which sh_mobile_lcdcfb is used.
>
> In any case, for x86 and arm64 today, commit 37b4837959cb9 is not
> sufficient to support contiguous kernel memory framebuffers. The problem
> can be seen with the hyperv_fb driver, which may allocate the framebuffer
> memory using vmalloc() or alloc_pages(), depending on the configuration
> of the Hyper-V guest VM (Gen 1 vs. Gen 2) and the size of the framebuffer.
That langugage is far too nice. The existing users of fb_defio are
all gravely broken because they violate the dma API restriction to
not poke into the memory. You can't speculate what you get from
dma_alloc_coherent and it can change behind you all the time.
> Fix this limitation by adding defio support for contiguous kernel memory
> framebuffers. A driver with a framebuffer allocated from contiguous
> kernel memory must set the FBINFO_KMEMFB flag to indicate such.
Honestly, the right thing is to invert the flag. What hypervs is doing
here - take kernel memory in the direct mapping or from vmalloc is fine.
What others drivers do it completely broken crap. So add a flag
FBINFO_BROKEN_CRAP to maybe keep the guessing. Or just disable it
because it's dangerous.
