From: Christoph Hellwig <h...@lst.de> Sent: Thursday, April 10, 2025 12:42 AM > > On Wed, Apr 09, 2025 at 02:10:26PM +0000, Michael Kelley wrote: > > Hmmm. What's the reference to "as told last time"? I don't think I've had > > this conversation before. > > Hmm, there was a conversation about deferred I/O, and I remember the > drm folks even defending their abuse of vmalloc_to_page on dma coherent > memory against the documentation in the most silly way. Maybe that was > a different discussion of the same thing.
Yes, must have been a different discussion. Turns out the hyperv_fb driver in a different configuration *is* using dma_alloc_coherent() to get framebuffer memory, which is then managed by deferred I/O. dma_alloc_coherent() is used as a wrapper around cma_alloc() but only when the framebuffer size is > 4 MiB. The deferred I/O code doesn't do vmalloc_to_page() since the CPU address from dma_alloc_coherent() isn't a vmalloc addr. That combo works OK, so wasn't something to be fixed in this patch set. I'll see about a separate patch to just use cma_alloc() directly for that case, though cma_alloc() and cma_release() would need to be EXPORTed. > > > > > For the hyperv_fb driver, the memory in question is allocated with a direct > > call > > to alloc_pages(), not via dma_alloc_coherent(). There's no DMA in this > > scenario. > > The memory is shared with the Hyper-V host and designated as the memory > > for the virtual framebuffer device. It is then mapped into user space using > > the > > mmap() system call against /dev/fb0. User space writes to the memory are > > eventually (and I omit the details) picked up by the Hyper-V host and > > displayed. > > Oh, great. > > > Is your point that memory dma_alloc_coherent() memory must be treated as > > a black box, and can't be deconstructed into individual pages? If so, that > > makes > > sense to me. > > Yes. I'll add some comments to the fbdev deferred I/O code saying not to use it with a framebuffer allocated with dma_alloc_coherent(). Thanks, Michael > > > But must the same treatment be applied to memory from > > alloc_pages()? This is where I need some education. > > No, that's just fine.
