From: Peter Xu <peterx@redhat.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: "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 Hildenbrand <david@redhat.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: Thu, 18 Jul 2024 10:03:01 -0400 [thread overview]
Message-ID: <ZpkglfpbHH7lQSft@x1n> (raw)
In-Reply-To: <Zph051h5BsSFMpR6@yzhao56-desk.sh.intel.com>
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.
> 2. Export track_pfn_remap() and call track_pfn_remap() in mmap() for pfn
> set 2.
> 3. Unmap and call vmf_insert_pfn() in the fault handler to map pfn set 2.
IMO this should be the similar case of MMIO being disabled on the bar,
where we can use track_pfn_remap() to register the whole vma in mmap()
first. Then in this case if you prefer proactive injection of partial of
the pfn mappings, one can do that via vmf_insert_pfn*() in mmap() after the
memtype registered.
>
> However, I'm not sure if we can properly untrack both pfn sets 1 and 2.
Untrack should so far only happen per-vma, AFAIU, so "set 1+2" need to be
done together as they belong to the same vma.
>
> By exporting untrack_pfn() too? Or, you'll leave VFIO to use ioremap/iounmap()
> (or the variants) to reserve memtype by itself?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-07-18 14:03 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 [this message]
2024-07-18 23:18 ` Yan Zhao
2024-07-19 8:28 ` David Hildenbrand
2024-07-19 14:13 ` Peter Xu
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=ZpkglfpbHH7lQSft@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.