From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alex Williamson <alex.williamson@redhat.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"Kirill A . Shutemov" <kirill@shutemov.name>,
"x86@kernel.org" <x86@kernel.org>,
"Tian, Kevin" <kevin.tian@intel.com>,
Pei Li <peili.dev@gmail.com>, David Wang <00107082@163.com>,
Bert Karwatzki <spasswolf@web.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region
Date: Fri, 19 Jul 2024 10:13:33 -0400 [thread overview]
Message-ID: <Zpp0jX_x2awQk6Nj@x1n> (raw)
In-Reply-To: <1a0884cb-39ed-455e-a505-7c1b2a0e5225@redhat.com>
On Fri, Jul 19, 2024 at 10:28:09AM +0200, David Hildenbrand wrote:
> On 19.07.24 01:18, Yan Zhao wrote:
> > On Thu, Jul 18, 2024 at 10:03:01AM -0400, Peter Xu wrote:
> > > On Thu, Jul 18, 2024 at 09:50:31AM +0800, Yan Zhao wrote:
> > > > Ok. Then if we have two sets of pfns, then we can
> > > > 1. Call remap_pfn_range() in mmap() for pfn set 1.
> > >
> > > I don't think this will work.. At least from the current implementation,
> > > remap_pfn_range() will only reserve the memtype if the range covers the
> > > whole vma.
> > Hmm, by referring to pfn set 1 and pfn set 2, I mean that they're both
> > covering the entire vma, but at different times.
> >
> > To make it more accurately:
> >
> > Consider this hypothetical scenario (not the same as what's implemented in
> > vfio-pci, but seems plausible):
> >
> > Suppose we have a vma covering only one page, then
> > (1) Initially, the vma is mapped to pfn1, with remap_pfn_range().
> > (2) Subsequently, unmap_single_vma() is invoked to unmap the entire VMA.
> > (3) The driver then maps the entire vma to pfn2 in fault handler
> >
> > Given this context, my questions are:
> > 1. How can we reserve the memory type for pfn2? Should we call
> > track_pfn_remap() in mmap() in advance?
> > 2. How do we untrack the memory type for pfn1 and pfn2, considering they
> > belong to the same VMA but mutual exclusively and not concurrently?
>
> Do we really have to support such changing PFNs in a VMA? Are there existing
> use cases that would rely on that?
I share the same question with David. I don't think we support that, and I
don't know whether we should, either.
Such flexibility already will break with current PAT design. See:
untrack_pfn:
if (!paddr && !size) {
if (get_pat_info(vma, &paddr, NULL))
return;
size = vma->vm_end - vma->vm_start;
}
free_pfn_range(paddr, size); <---- assumes PFNs to be continuous
So untrack_pfn() already assumed the pfn being continuous. I think it
means pfns cannot be randomly faulted in, but determined when mmap().
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-07-19 14:13 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-12 14:42 [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region Peter Xu
2024-07-13 1:18 ` David Hildenbrand
2024-07-13 3:36 ` David Wang
2024-07-14 10:59 ` David Wang
2024-07-14 18:27 ` [PATCH] " David Hildenbrand
2024-07-15 15:03 ` Peter Xu
2024-07-17 14:14 ` David Hildenbrand
2024-07-17 16:27 ` Peter Xu
2024-07-15 7:08 ` Yan Zhao
2024-07-15 14:29 ` Peter Xu
2024-07-16 9:13 ` Yan Zhao
2024-07-16 19:01 ` Peter Xu
2024-07-17 1:38 ` Yan Zhao
2024-07-17 14:15 ` Peter Xu
2024-07-18 1:50 ` Yan Zhao
2024-07-18 14:03 ` Peter Xu
2024-07-18 23:18 ` Yan Zhao
2024-07-19 8:28 ` David Hildenbrand
2024-07-19 14:13 ` Peter Xu [this message]
2024-07-22 6:49 ` Yan Zhao
2024-07-22 13:52 ` Peter Xu
2024-07-22 6:43 ` Yan Zhao
2024-07-22 9:17 ` David Hildenbrand
2024-07-23 20:27 ` Peter Xu
2024-07-23 21:36 ` David Hildenbrand
2024-07-23 21:44 ` Jason Gunthorpe
2024-07-24 8:53 ` David Hildenbrand
2024-07-17 14:17 ` David Hildenbrand
2024-07-17 16:30 ` Peter Xu
2024-07-17 16:31 ` Jason Gunthorpe
2024-07-17 18:10 ` Peter Xu
2024-07-17 16:32 ` David Hildenbrand
2024-07-17 18:12 ` Peter Xu
2024-07-20 2:18 ` Liam R. Howlett
2024-07-22 15:15 ` Peter Xu
2024-07-22 20:22 ` Liam R. Howlett
2024-07-22 21:17 ` Peter Xu
2024-07-23 10:12 ` David Hildenbrand
2024-07-23 17:58 ` Liam R. Howlett
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=Zpp0jX_x2awQk6Nj@x1n \
--to=peterx@redhat.com \
--cc=00107082@163.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peili.dev@gmail.com \
--cc=peterz@infradead.org \
--cc=senozhatsky@chromium.org \
--cc=spasswolf@web.de \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
--cc=yan.y.zhao@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.