On Mon, Aug 04, 2025 at 11:51:38AM +1000, Alistair Popple wrote:
> On Fri, Aug 01, 2025 at 01:57:49PM -0300, Jason Gunthorpe wrote:
> > On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote:
> > > On 01.08.25 18:40, Jason Gunthorpe wrote:
> > > > On Fri, Jul 25, 2025 at 10:31:25AM +1000
On 01.08.25 18:57, Jason Gunthorpe wrote:
On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote:
On 01.08.25 18:40, Jason Gunthorpe wrote:
On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
The only issue would be if there were generic code paths that somehow have a
On Fri, Aug 01, 2025 at 01:57:49PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote:
> > On 01.08.25 18:40, Jason Gunthorpe wrote:
> > > On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
> > >
> > > > The only issue would be if there
On Fri, Aug 01, 2025 at 06:50:18PM +0200, David Hildenbrand wrote:
> On 01.08.25 18:40, Jason Gunthorpe wrote:
> > On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
> >
> > > The only issue would be if there were generic code paths that somehow
> > > have a
> > > raw pfn obtained f
On Sun, Jul 20, 2025 at 11:59:10PM -0700, Christoph Hellwig wrote:
> > + /*
> > +* Don't fault in device private pages owned by the caller,
> > +* just report the PFN.
> > +*/
> > + if (pgmap->owner == range->dev_private_owner) {
> > + *hmm_pfn = swp_offset_pfn(entry);
> >
On 01.08.25 18:40, Jason Gunthorpe wrote:
On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
The only issue would be if there were generic code paths that somehow have a
raw pfn obtained from neither a page-table walk or struct page. My assumption
(yet to be proven/tested) is that
On Fri, Jul 25, 2025 at 10:31:25AM +1000, Alistair Popple wrote:
> The only issue would be if there were generic code paths that somehow have a
> raw pfn obtained from neither a page-table walk or struct page. My assumption
> (yet to be proven/tested) is that these paths don't exist.
hmm does it,
On 25.07.25 02:31, Alistair Popple wrote:
On Thu, Jul 24, 2025 at 10:52:54AM +0200, David Hildenbrand wrote:
On 23.07.25 06:10, Alistair Popple wrote:
On Wed, Jul 23, 2025 at 12:51:42AM -0300, Jason Gunthorpe wrote:
On Tue, Jul 22, 2025 at 10:49:10AM +1000, Alistair Popple wrote:
So what is i
On Thu, Jul 24, 2025 at 10:52:54AM +0200, David Hildenbrand wrote:
> On 23.07.25 06:10, Alistair Popple wrote:
> > On Wed, Jul 23, 2025 at 12:51:42AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Jul 22, 2025 at 10:49:10AM +1000, Alistair Popple wrote:
> > > > > So what is it?
> > > >
> > > > IMHO a
On 23.07.25 06:10, Alistair Popple wrote:
On Wed, Jul 23, 2025 at 12:51:42AM -0300, Jason Gunthorpe wrote:
On Tue, Jul 22, 2025 at 10:49:10AM +1000, Alistair Popple wrote:
So what is it?
IMHO a hack, because obviously we shouldn't require real physical addresses for
something the CPU can't ac
On Wed, Jul 23, 2025 at 12:51:42AM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 22, 2025 at 10:49:10AM +1000, Alistair Popple wrote:
> > > So what is it?
> >
> > IMHO a hack, because obviously we shouldn't require real physical addresses
> > for
> > something the CPU can't actually address anyway
On Tue, Jul 22, 2025 at 10:49:10AM +1000, Alistair Popple wrote:
> > So what is it?
>
> IMHO a hack, because obviously we shouldn't require real physical addresses
> for
> something the CPU can't actually address anyway and this causes real
> problems
IMHO what DEVICE PRIVATE really boils down t
On 21/07/2025 9:59, Christoph Hellwig wrote:
On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
From: Yonatan Maman
hmm_range_fault() by default triggered a page fault on device private
when HMM_PFN_REQ_FAULT flag was set. pages, migrating them to RAM. In some
cases, such as wit
On Mon, Jul 21, 2025 at 02:23:13PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 18, 2025 at 11:44:42AM -0300, Jason Gunthorpe wrote:
> > On Fri, Jul 18, 2025 at 03:17:00PM +0100, Matthew Wilcox wrote:
> > > On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> > > > +++ b/include/linux/mem
On Fri, Jul 18, 2025 at 11:44:42AM -0300, Jason Gunthorpe wrote:
> On Fri, Jul 18, 2025 at 03:17:00PM +0100, Matthew Wilcox wrote:
> > On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> > > +++ b/include/linux/memremap.h
> > > @@ -89,6 +89,14 @@ struct dev_pagemap_ops {
> > >*/
>
On Fri, Jul 18, 2025 at 11:44:42AM -0300, Jason Gunthorpe wrote:
> On Fri, Jul 18, 2025 at 03:17:00PM +0100, Matthew Wilcox wrote:
> > On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> > > +++ b/include/linux/memremap.h
> > > @@ -89,6 +89,14 @@ struct dev_pagemap_ops {
> > >*/
>
On Fri, Jul 18, 2025 at 03:17:00PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> > +++ b/include/linux/memremap.h
> > @@ -89,6 +89,14 @@ struct dev_pagemap_ops {
> > */
> > vm_fault_t (*migrate_to_ram)(struct vm_fault *vmf);
> >
> > + /
On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> +++ b/include/linux/memremap.h
> @@ -89,6 +89,14 @@ struct dev_pagemap_ops {
>*/
> vm_fault_t (*migrate_to_ram)(struct vm_fault *vmf);
>
> + /*
> + * Used for private (un-addressable) device memory only. Retur
18 matches
Mail list logo
