mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Carlos López" <clopez@suse.de>
To: kvm@vger.kernel.org, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-riscv@lists.infradead.org, seanjc@google.com,
	pbonzini@redhat.com, akpm@linux-foundation.org, david@kernel.org,
	peterx@redhat.com, ljs@kernel.org, imbrenda@linux.ibm.com,
	borntraeger@linux.ibm.com, frankja@linux.ibm.com,
	"Carlos López" <clopez@suse.de>,
	"Steffen Eiden" <seiden@linux.ibm.com>,
	"Andreas Grapentin" <gra@linux.ibm.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>
Subject: [PATCH v2 9/9] KVM: s390: don't unmap the gmap on permission upgrade
Date: Thu,  5 Nov 2026 17:50:06 +0100	[thread overview]
Message-ID: <20261105165004.2663799-13-clopez@suse.de> (raw)
In-Reply-To: <20261105165004.2663799-4-clopez@suse.de>

When an mmu_notifier invalidation only upgrades permissions
(MMU_NOTIFIER_RANGE_PERM_UPGRADE), keep the existing gmap entries
instead of unmapping them. The PFN is unchanged and no access is
revoked, so an existing entry is no more permissive than the new host
PTE.

A write to an entry that is still read-only causes a protection
exception, which kvm_s390_faultin_gfn() handles as a write fault,
picking up the new permissions. This applies to both s390 and arm64
guests.

Signed-off-by: Carlos López <clopez@suse.de>
---
 arch/s390/kvm/arm64/arm.c | 7 +++++++
 arch/s390/kvm/s390/s390.c | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/s390/kvm/arm64/arm.c b/arch/s390/kvm/arm64/arm.c
index bd9d85235f43..5aee1817aad8 100644
--- a/arch/s390/kvm/arm64/arm.c
+++ b/arch/s390/kvm/arm64/arm.c
@@ -678,6 +678,13 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, struct kvm_memory_slot *old,
 
 bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
+	/*
+	 * Do not bother unmapping if this is only a protection upgrade.
+	 * Permissions will be faulted-in on demand.
+	 */
+	if (range->flags & MMU_NOTIFIER_RANGE_PERM_UPGRADE)
+		return false;
+
 	return gmap_unmap_gfn_range(kvm->arch.gmap, range->slot, range->start, range->end);
 }
 
diff --git a/arch/s390/kvm/s390/s390.c b/arch/s390/kvm/s390/s390.c
index 18fb200f854a..954bf6b64683 100644
--- a/arch/s390/kvm/s390/s390.c
+++ b/arch/s390/kvm/s390/s390.c
@@ -5871,6 +5871,13 @@ bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
  */
 bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
 {
+	/*
+	 * Do not bother unmapping if this is only a protection upgrade.
+	 * Permissions will be faulted-in on demand.
+	 */
+	if (range->flags & MMU_NOTIFIER_RANGE_PERM_UPGRADE)
+		return false;
+
 	return gmap_unmap_gfn_range(kvm->arch.gmap, range->slot, range->start, range->end);
 }
 
-- 
2.51.0


      parent reply	other threads:[~2026-11-05 17:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05 16:49 [PATCH v2 0/9] KVM: don't zap secondary MMU " Carlos López
2026-11-05 16:49 ` [PATCH v2 1/9] mm: fix eager write-bit restore for write-notified shared mappings Carlos López
2026-11-05 16:49 ` [PATCH v2 2/9] riscv: mm: add pud_soft_dirty() Carlos López
2026-11-05 16:50 ` [PATCH v2 3/9] mm/huge_memory: honor MM_CP_TRY_CHANGE_WRITABLE in change_huge_pud() Carlos López
2026-11-05 16:50 ` [PATCH v2 4/9] mm/mprotect: add MM_CP_PERM_UPGRADE Carlos López
2026-11-05 16:50 ` [PATCH v2 5/9] mm/mprotect: keep writable entries writable on permission upgrades Carlos López
2026-11-05 17:06   ` David Hildenbrand (Arm)
2026-11-05 16:50 ` [PATCH v2 6/9] mm/mmu_notifier: add MMU_NOTIFIER_RANGE_PERM_UPGRADE Carlos López
2026-11-05 16:50 ` [PATCH v2 7/9] KVM: pass the mmu_notifier event and flags to kvm_gfn_range Carlos López
2026-11-05 16:50 ` [PATCH v2 8/9] KVM: x86/mmu: don't zap secondary MMU on permission upgrade Carlos López
2026-11-05 16:50 ` Carlos López [this message]

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=20261105165004.2663799-13-clopez@suse.de \
    --to=clopez@suse.de \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=david@kernel.org \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=gra@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=seanjc@google.com \
    --cc=seiden@linux.ibm.com \
    --cc=svens@linux.ibm.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

all inboxes | Powered by JetHome®