Re: [PATCH v3 0/9] KVM: don't zap secondary MMU on permission upgrade

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/12/26 15:20, Carlos López wrote:
> Stop KVM from zapping its mappings on permission upgrades on x86 and
> s390, as these keep the PFNs unchanged and revoke no access. KVM faults
> in the new permissions on demand, so dropping mappings early gains
> nothing.
> 
> To do so, add an MMU notifier flag that marks an
> MMU_NOTIFY_PROTECTION_VMA invalidation as a strict permission upgrade.
> For the flag to be accurate, change_protection() keeps writable entries
> writable on such changes. A few cases where it needlessly makes or
> leaves entries read-only are fixed along the way.
> 
> Background
> ==========
> 
> change_protection() pairs every protection change with an
> MMU_NOTIFY_PROTECTION_VMA invalidation, and KVM zaps its SPTEs in
> response, as it cannot tell whether permissions widened or narrowed.
> This is costly, e.g. during a QEMU background snapshot, which uses
> uffd-wp to write-protect guest RAM and unprotects each page once it is
> saved. Every unprotect then makes the guest refault memory it could
> already access.
> 
> Secondary MMUs that share the CPU page tables (e.g. ARM SMMU,
> IOMMU/ATS) can keep read-only entries in their TLBs that a fault does
> not flush, so they are already notified of permission upgrades on the
> CPU TLB flush path [1]. KVM keeps its own page tables and faults in
> permissions on demand, so it needs no notification, as Sean noted when
> that signalling was first proposed [2].
> 
> Series overview
> ===============
> 
> Patches 1-4 fix cases where change_protection() needlessly makes or
> leaves entries read-only, so that the next write to them faults. They
> only affect performance and can be picked up independently.

We generally don't add performance improvements without clear motivation and
data to back it up.

MM is currently busy with more important stuff, so best to keep your changes to
a bare minimum.

-- 
Cheers,

David