linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michael Kelley <mhklinux@outlook.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "jayalk@intworks.biz" <jayalk@intworks.biz>,
	"simona@ffwll.ch" <simona@ffwll.ch>,
	"deller@gmx.de" <deller@gmx.de>,
	"haiyangz@microsoft.com" <haiyangz@microsoft.com>,
	"kys@microsoft.com" <kys@microsoft.com>,
	"wei.liu@kernel.org" <wei.liu@kernel.org>,
	"decui@microsoft.com" <decui@microsoft.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"weh@microsoft.com" <weh@microsoft.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite()
Date: Fri, 11 Apr 2025 03:40:25 +0000	[thread overview]
Message-ID: <SN6PR02MB4157209BE242E68F85908126D4B62@SN6PR02MB4157.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20250410074228.GA680@lst.de>

From: Christoph Hellwig <hch@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.



  reply	other threads:[~2025-04-11  3:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08 18:36 [PATCH 0/3] fbdev: Add deferred I/O support for contiguous kernel memory framebuffers mhkelley58
2025-04-08 18:36 ` [PATCH 1/3] mm: Export vmf_insert_mixed_mkwrite() mhkelley58
2025-04-09 10:49   ` Christoph Hellwig
2025-04-09 14:10     ` Michael Kelley
2025-04-10  7:42       ` Christoph Hellwig
2025-04-11  3:40         ` Michael Kelley [this message]
2025-04-08 18:36 ` [PATCH 2/3] fbdev/deferred-io: Support contiguous kernel memory framebuffers mhkelley58
2025-04-09 10:50   ` Christoph Hellwig
2025-04-08 18:36 ` [PATCH 3/3] fbdev: hyperv_fb: Fix mmap of framebuffers allocated using alloc_pages() mhkelley58

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN6PR02MB4157209BE242E68F85908126D4B62@SN6PR02MB4157.namprd02.prod.outlook.com \
    --to=mhklinux@outlook.com \
    --cc=akpm@linux-foundation.org \
    --cc=decui@microsoft.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=haiyangz@microsoft.com \
    --cc=hch@lst.de \
    --cc=jayalk@intworks.biz \
    --cc=kys@microsoft.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=weh@microsoft.com \
    --cc=wei.liu@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox