From: Alistair Popple <apopple@nvidia.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>
Cc: Jordan Niethe <jniethe@nvidia.com>,
linux-mm@kvack.org, balbirs@nvidia.com, matthew.brost@intel.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, ziy@nvidia.com,
lorenzo.stoakes@oracle.com, lyude@redhat.com, dakr@kernel.org,
airlied@gmail.com, simona@ffwll.ch, rcampbell@nvidia.com,
mpenttil@redhat.com, jgg@nvidia.com, willy@infradead.org
Subject: Re: [RFC PATCH 0/6] Remove device private pages from physical address space
Date: Mon, 1 Dec 2025 10:33:20 +1100 [thread overview]
Message-ID: <dklhe7gbudew5mdgrxzhrw3wqnnqigapbtetnn4gpaktlkpiyh@kohwt6syeapn> (raw)
In-Reply-To: <301376ee-3439-4d3e-a2c9-8604e7bf49fb@kernel.org>
On 2025-11-28 at 18:40 +1100, "David Hildenbrand (Red Hat)" <david@kernel.org> wrote...
> On 11/28/25 05:41, Jordan Niethe wrote:
> > Today, when creating these device private struct pages, the first step
> > is to use request_free_mem_region() to get a range of physical address
> > space large enough to represent the devices memory. This allocated
> > physical address range is then remapped as device private memory using
> > memremap_pages.
>
> Just a note that as we are finishing the old release and are about to start
> the merge window (+ there is Thanksgiving), expect few replies to non-urgent
> stuff in the next weeks.
Thanks David! Mostly we just wanted to at least get the RFC out prior to LPC so
I can talk about it there if needed.
> Having that said, the proposal is interesting. I recall that Alistair and
> Jason recently discussed removing the need of dealing with PFNs
> completely for device-private.
>
> Is that the result of these discussions?
That is certainly something we would like to explore, but this idea mostly came
from a more immediate need to deal with the lack of support on AARCH64 where we
can't just steal random bits of the physical address space (which is reasonable
- the kernel doesn't really "own" the physical memory map after all), and also
the KASLR and VM issues which cause initialisation to fail.
Removing struct pages entirely for at least device private memory is also
something I'd like to explore with this.
> --
> Cheers
>
> David
next prev parent reply other threads:[~2025-11-30 23:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 4:41 Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 1/6] mm/hmm: Add flag to track device private PFNs Jordan Niethe
2025-11-28 18:36 ` Matthew Brost
2025-12-02 1:20 ` Jordan Niethe
2025-12-03 4:25 ` Balbir Singh
2025-11-28 4:41 ` [RFC PATCH 2/6] mm/migrate_device: Add migrate PFN " Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 3/6] mm/page_vma_mapped: Add flags to page_vma_mapped_walk::pfn " Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 4/6] mm: Add a new swap type for migration entries with " Jordan Niethe
2025-12-01 2:43 ` Chih-En Lin
2025-12-02 1:42 ` Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 5/6] mm/util: Add flag to track device private PFNs in page snapshots Jordan Niethe
2025-11-28 4:41 ` [RFC PATCH 6/6] mm: Remove device private pages from the physical address space Jordan Niethe
2025-11-28 17:51 ` Jason Gunthorpe
2025-12-02 2:28 ` Jordan Niethe
2025-12-02 4:10 ` Alistair Popple
2025-11-28 7:40 ` [RFC PATCH 0/6] Remove device private pages from " David Hildenbrand (Red Hat)
2025-11-30 23:33 ` Alistair Popple [this message]
2025-11-28 15:09 ` Matthew Wilcox
2025-12-02 1:31 ` Jordan Niethe
2025-11-28 16:07 ` Mika Penttilä
2025-12-02 1:32 ` Jordan Niethe
2025-11-28 19:22 ` Matthew Brost
2025-11-30 23:23 ` Alistair Popple
2025-12-01 1:51 ` Matthew Brost
2025-12-02 1:40 ` Jordan Niethe
2025-12-02 22:20 ` Balbir Singh
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=dklhe7gbudew5mdgrxzhrw3wqnnqigapbtetnn4gpaktlkpiyh@kohwt6syeapn \
--to=apopple@nvidia.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=balbirs@nvidia.com \
--cc=dakr@kernel.org \
--cc=david@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=jniethe@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lyude@redhat.com \
--cc=matthew.brost@intel.com \
--cc=mpenttil@redhat.com \
--cc=rcampbell@nvidia.com \
--cc=simona@ffwll.ch \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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