From: Sean Christopherson <seanjc@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: Yan Zhao <yan.y.zhao@intel.com>,
Michael Roth <michael.roth@amd.com>,
pbonzini@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, rick.p.edgecombe@intel.com,
kai.huang@intel.com, adrian.hunter@intel.com,
reinette.chatre@intel.com, xiaoyao.li@intel.com,
tony.lindgren@intel.com, binbin.wu@linux.intel.com,
dmatlack@google.com, isaku.yamahata@intel.com,
ira.weiny@intel.com, vannapurve@google.com,
ackerleytng@google.com, tabba@google.com, chao.p.peng@intel.com
Subject: Re: [RFC PATCH] KVM: TDX: Decouple TDX init mem region from kvm_gmem_populate()
Date: Mon, 14 Jul 2025 09:07:05 -0700 [thread overview]
Message-ID: <aHUrKWaixqJyhsUU@google.com> (raw)
In-Reply-To: <c5c964cd-947e-43ff-9c79-18c1555aea8e@redhat.com>
On Mon, Jul 14, 2025, David Hildenbrand wrote:
> On 14.07.25 17:46, Sean Christopherson wrote:
> > On Mon, Jul 14, 2025, Yan Zhao wrote:
> > > On Fri, Jul 11, 2025 at 08:39:59AM -0700, Sean Christopherson wrote:
> > > > The below could be tweaked to batch get_user_pages() into an array of pointers,
> > > > but given that both SNP and TDX can only operate on one 4KiB page at a time, and
> > > > that hugepage support doesn't yet exist, trying to super optimize the hugepage
> > > > case straightaway doesn't seem like a pressing concern.
> > >
> > > > static long __kvm_gmem_populate(struct kvm *kvm, struct kvm_memory_slot *slot,
> > > > struct file *file, gfn_t gfn, void __user *src,
> > > > kvm_gmem_populate_cb post_populate, void *opaque)
> > > > {
> > > > pgoff_t index = kvm_gmem_get_index(slot, gfn);
> > > > struct page *src_page = NULL;
> > > > bool is_prepared = false;
> > > > struct folio *folio;
> > > > int ret, max_order;
> > > > kvm_pfn_t pfn;
> > > >
> > > > if (src) {
> > > > ret = get_user_pages((unsigned long)src, 1, 0, &src_page);
> > > get_user_pages_fast()?
> > >
> > > get_user_pages() can't pass the assertion of mmap_assert_locked().
> >
> > Oh, I forgot get_user_pages() requires mmap_lock to already be held. I would
> > prefer to not use a fast variant, so that userspace isn't required to prefault
> > (and pin?) the source.
> >
> > So get_user_pages_unlocked()?
>
> Yes, but likely we really want get_user_pages_fast(), which will fallback to
> GUP-slow (+take the lock) in case it doesn't find what it needs in the page
> tables.
>
> get_user_pages_fast_only() would be the variant that doesn't fallback to
> GUP-slow.
Doh, right, that's indeed what I want.
next prev parent reply other threads:[~2025-07-14 16:07 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 6:26 [RFC PATCH] KVM: TDX: Decouple TDX init mem region from kvm_gmem_populate() Yan Zhao
2025-07-03 16:51 ` Vishal Annapurve
2025-07-09 23:21 ` Michael Roth
2025-07-10 16:24 ` Sean Christopherson
2025-07-11 1:41 ` Ira Weiny
2025-07-11 14:21 ` Sean Christopherson
2025-07-11 4:36 ` Yan Zhao
2025-07-11 15:17 ` Michael Roth
2025-07-11 15:39 ` Sean Christopherson
2025-07-11 16:34 ` Michael Roth
2025-07-11 18:38 ` Vishal Annapurve
2025-07-11 19:49 ` Michael Roth
2025-07-11 20:19 ` Sean Christopherson
2025-07-11 20:25 ` Ira Weiny
2025-07-11 22:56 ` Sean Christopherson
2025-07-11 23:04 ` Vishal Annapurve
2025-07-14 23:11 ` Ira Weiny
2025-07-15 0:41 ` Vishal Annapurve
2025-07-14 23:08 ` Ira Weiny
2025-07-14 23:12 ` Sean Christopherson
2025-07-11 18:46 ` Vishal Annapurve
2025-07-12 17:38 ` Vishal Annapurve
2025-07-14 6:15 ` Yan Zhao
2025-07-14 15:46 ` Sean Christopherson
2025-07-14 16:02 ` David Hildenbrand
2025-07-14 16:07 ` Sean Christopherson [this message]
2025-07-15 1:10 ` Yan Zhao
2025-07-18 9:14 ` Yan Zhao
2025-07-18 15:57 ` Vishal Annapurve
2025-07-18 18:42 ` Ira Weiny
2025-07-18 18:59 ` Vishal Annapurve
2025-07-21 17:46 ` Ira Weiny
2025-07-28 9:48 ` Yan Zhao
2025-07-29 0:45 ` Vishal Annapurve
2025-07-29 1:37 ` Yan Zhao
2025-07-29 16:33 ` Ira Weiny
2025-08-05 0:22 ` Sean Christopherson
2025-08-05 1:20 ` Vishal Annapurve
2025-08-05 14:30 ` Vishal Annapurve
2025-08-05 19:59 ` Sean Christopherson
2025-08-06 0:09 ` Vishal Annapurve
2025-07-14 3:20 ` Yan Zhao
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=aHUrKWaixqJyhsUU@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.p.peng@intel.com \
--cc=david@redhat.com \
--cc=dmatlack@google.com \
--cc=ira.weiny@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tabba@google.com \
--cc=tony.lindgren@intel.com \
--cc=vannapurve@google.com \
--cc=xiaoyao.li@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).