From: "Huang, Kai" <kai.huang@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"michael.roth@amd.com" <michael.roth@amd.com>
Cc: "david@redhat.com" <david@redhat.com>,
"liam.merwick@oracle.com" <liam.merwick@oracle.com>,
"seanjc@google.com" <seanjc@google.com>,
"aik@amd.com" <aik@amd.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Annapurve, Vishal" <vannapurve@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"vbabka@suse.cz" <vbabka@suse.cz>,
"ashish.kalra@amd.com" <ashish.kalra@amd.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"Weiny, Ira" <ira.weiny@intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"ackerleytng@google.com" <ackerleytng@google.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: Re: [PATCH v2 2/5] KVM: guest_memfd: Remove preparation tracking
Date: Thu, 18 Dec 2025 22:53:14 +0000 [thread overview]
Message-ID: <35e79cadf079622588ddb9fac0ccc985751dd81b.camel@intel.com> (raw)
In-Reply-To: <20251215153411.3613928-3-michael.roth@amd.com>
> /*
> * Process @folio, which contains @gfn, so that the guest can use it.
> * The folio must be locked and the gfn must be contained in @slot.
> @@ -90,13 +85,7 @@ static inline void kvm_gmem_mark_prepared(struct folio *folio)
> static int kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slot,
> gfn_t gfn, struct folio *folio)
> {
> - unsigned long nr_pages, i;
> pgoff_t index;
> - int r;
> -
> - nr_pages = folio_nr_pages(folio);
> - for (i = 0; i < nr_pages; i++)
> - clear_highpage(folio_page(folio, i));
>
Here the entire folio is cleared, but ...
[...]
> - folio = __kvm_gmem_get_pfn(file, slot, index, pfn, &is_prepared, max_order);
> + folio = __kvm_gmem_get_pfn(file, slot, index, pfn, max_order);
> if (IS_ERR(folio))
> return PTR_ERR(folio);
>
> - if (!is_prepared)
> - r = kvm_gmem_prepare_folio(kvm, slot, gfn, folio);
> + if (!folio_test_uptodate(folio)) {
> + clear_highpage(folio_page(folio, 0));
> + folio_mark_uptodate(folio);
> + }
... here only the first page is cleared.
I understand currently there's no huge folio coming out of gmem now, but
since both __kvm_gmem_get_pfn() and kvm_gmem_get_pfn() still have
@max_level as output, it's kinda inconsistent here.
I also see kvm_gmem_fault_user_mapping() only clears the first page too,
but I think that already has assumption that folio can never be huge
currently?
Given this, and the fact that the first patch of this series has
introduced
WARN_ON_ONCE(folio_order(folio));
in kvm_gmem_get_folio(), I think it's fine to only clear the first page,
but for the sake of consistency, perhaps we should just remove @max_order
from __kvm_gmem_get_pfn() and kvm_gmem_get_pfn()?
Then we can handle huge folio logic when that comes to play.
Btw:
I actually looked into the RFC v1 discussion but the code there actually
does a loop to clear all pages in the folio. There were some other
discussions about AFAICT they were more related to issues regarding to
"mark entire folio as uptodate while only one page is processed in
post_populate()".
Btw2:
There was also discussion that clearing page isn't required for TDX. To
that end, maybe we can remove clearing page from gmem common code but to
SEV code, e.g., as part of "folio preparation"?
next prev parent reply other threads:[~2025-12-18 22:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 15:34 [PATCH v2 0/5] KVM: guest_memfd: Rework preparation/population flows in prep for in-place conversion Michael Roth
2025-12-15 15:34 ` [PATCH v2 1/5] KVM: guest_memfd: Remove partial hugepage handling from kvm_gmem_populate() Michael Roth
2025-12-16 0:12 ` Vishal Annapurve
2025-12-16 0:18 ` Sean Christopherson
2025-12-26 2:49 ` Yan Zhao
2025-12-15 15:34 ` [PATCH v2 2/5] KVM: guest_memfd: Remove preparation tracking Michael Roth
2025-12-16 0:13 ` Vishal Annapurve
2025-12-16 3:29 ` Gupta, Pankaj
2025-12-18 22:53 ` Huang, Kai [this message]
2025-12-15 15:34 ` [PATCH v2 3/5] KVM: SEV: Document/enforce page-alignment for KVM_SEV_SNP_LAUNCH_UPDATE Michael Roth
2025-12-16 0:15 ` Vishal Annapurve
2025-12-15 15:34 ` [PATCH v2 4/5] KVM: TDX: Document alignment requirements for KVM_TDX_INIT_MEM_REGION Michael Roth
2025-12-16 0:19 ` Vishal Annapurve
2025-12-15 15:34 ` [PATCH v2 5/5] KVM: guest_memfd: GUP source pages prior to populating guest memory Michael Roth
2025-12-16 0:18 ` Vishal Annapurve
2025-12-18 22:24 ` Huang, Kai
2025-12-26 2:48 ` Yan Zhao
2025-12-26 3:09 ` Yan Zhao
2025-12-18 22:55 ` [PATCH v2 0/5] KVM: guest_memfd: Rework preparation/population flows in prep for in-place conversion Huang, Kai
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=35e79cadf079622588ddb9fac0ccc985751dd81b.camel@intel.com \
--to=kai.huang@intel.com \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=ashish.kalra@amd.com \
--cc=david@redhat.com \
--cc=ira.weiny@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liam.merwick@oracle.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=thomas.lendacky@amd.com \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--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