From: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
To: linux-coco@lists.linux.dev
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>,
Ackerley Tng <ackerleytng@google.com>,
Alex Williamson <alex@shazbot.org>,
David Woodhouse <dwmw2@infradead.org>,
David Hildenbrand <david@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Kevin Tian <kevin.tian@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Robin Murphy <robin.murphy@arm.com>,
Sean Christopherson <seanjc@google.com>,
Will Deacon <will@kernel.org>, Alexey Kardashevskiy <aik@amd.com>,
Xu Yilun <yilun.xu@linux.intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Fred Griffoul <griffoul@gmail.com>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
patches@lists.linux.dev
Subject: [RFC PATCH v3 10/13] KVM: guest_memfd: Support range revocation of device mappings
Date: Sun, 1 Nov 2026 12:49:24 +0530 [thread overview]
Message-ID: <20261101071928.2462549-11-aneesh.kumar@kernel.org> (raw)
In-Reply-To: <20261101071928.2462549-1-aneesh.kumar@kernel.org>
Give device backing a revoke operation that removes host and both shared
and private guest translations under provider exclusion, without reclaiming
MMIO PFNs or changing attributes. Keep fallocate and hole punching
unsupported for device memory.
Range revocation does not exclude new faults after returning. Providers
must preserve the underlying resource and call without provider locks held,
since inode exclusion precedes provider exclusion. Private attributes
continue to describe ownership until explicitly changed or the file closes.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
virt/kvm/guest_memfd.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
index 1322576350b8..cfb7f34c0180 100644
--- a/virt/kvm/guest_memfd.c
+++ b/virt/kvm/guest_memfd.c
@@ -559,6 +559,18 @@ static int kvm_gmem_ram_pfn_revoke(struct inode *inode, pgoff_t start, pgoff_t e
return 0;
}
+static int kvm_gmem_device_revoke(struct inode *inode, pgoff_t start, pgoff_t end,
+ const unsigned long *pfn, bool put_pfn_range)
+{
+ /*
+ * Common invalidation handles shared and private guest mappings. Only
+ * host userspace mappings need to be unmapped here; MMIO has no RAM
+ * pages to reclaim or provider allocations to release.
+ */
+ unmap_mapping_pages(inode->i_mapping, start, end - start, true);
+ return 0;
+}
+
static int __kvm_gmem_revoke(struct inode *inode, pgoff_t start,
size_t nr_pages, const unsigned long *pfn,
bool put_pfn_range)
@@ -622,7 +634,11 @@ static long kvm_gmem_punch_hole(struct inode *inode, loff_t offset, loff_t len)
*
* Must be called before accessing memory contents. Keeping the mapping from
* @start to @pfn constant is the responsibility of the caller.
- * .put_pfn_range() will not be called.
+ * .put_pfn_range() will not be called. For device memory, this revokes host
+ * and both shared and private guest mappings under provider exclusion, without
+ * changing attributes or releasing BAR PFNs. Call without provider locks held:
+ * inode exclusion precedes provider exclusion. This does not exclude new faults
+ * after returning; the provider must preserve the backing resource.
*
* Return: 0 on success, or a negative error code on failure.
*/
@@ -1185,6 +1201,7 @@ static const struct kvm_gmem_backing_ops kvm_gmem_ram_pfn_backing_ops = {
};
static const struct kvm_gmem_backing_ops kvm_gmem_device_backing_ops = {
+ .revoke = kvm_gmem_device_revoke,
.prepare_attributes = kvm_gmem_pfn_prepare_attributes,
.make_private = kvm_gmem_device_make_private,
.make_shared = kvm_gmem_noop_conversion,
--
2.43.0
next prev parent reply other threads:[~2026-11-01 7:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 7:19 [RFC PATCH v3 00/13] KVM: guest_memfd: Add a common framework for device memory providers Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 01/13] KVM: guest_memfd: Let providers prepare memory regions Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 02/13] KVM: guest_memfd: Dispatch attribute conversion through backing operations Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 03/13] KVM: guest_memfd: Let providers coordinate mapping changes Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 04/13] KVM: guest_memfd: Dispatch revocation through backing operations Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 05/13] KVM: guest_memfd: Split population by backing type Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 06/13] KVM: guest_memfd: Support device-backed PFN providers Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 07/13] KVM: guest_memfd: Support private/shared conversion of device memory Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 08/13] KVM: guest_memfd: Track private device ranges after attribute updates Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 09/13] KVM: guest_memfd: Expose device provider private state Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` Aneesh Kumar K.V (Arm) [this message]
2026-11-01 7:19 ` [RFC PATCH v3 11/13] KVM: guest_memfd: Add shared device mmap through PFN providers Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 12/13] KVM: guest_memfd: Remove device mappings on final close Aneesh Kumar K.V (Arm)
2026-11-01 7:19 ` [RFC PATCH v3 13/13] KVM: guest_memfd: Invalidate guest_memfd mappings before removing memslot bindings Aneesh Kumar K.V (Arm)
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=20261101071928.2462549-11-aneesh.kumar@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=alex@shazbot.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dwmw2@infradead.org \
--cc=griffoul@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=patches@lists.linux.dev \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yilun.xu@linux.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.