From: Ankit Agrawal <ankita@nvidia.com>
Introduce a new KVM capability to expose to the userspace whether
cacheable mapping of PFNMAP is supported.
The ability to safely do the cacheable mapping of PFNMAP is contingent
on S2FWB and ARM64_HAS_CACHE_DIC. S2FWB allows KVM to avoid flushing
the D cache, ARM64_HAS_CACHE_DIC allows KVM to avoid flushing the icache
and turns icache_inval_pou() into a NOP. The cap would be false if
those requirements are missing and is checked by making use of
kvm_arch_supports_cacheable_pfnmap.
This capability would allow userspace to discover the support.
It could for instance be used by userspace to prevent live-migration
across FWB and non-FWB hosts.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Jason Gunthorpe <jgg@nvidia.com>
CC: Oliver Upton <oliver.upton@linux.dev>
CC: David Hildenbrand <david@redhat.com>
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
---
Documentation/virt/kvm/api.rst | 13 ++++++++++++-
arch/arm64/kvm/arm.c | 7 +++++++
include/uapi/linux/kvm.h | 1 +
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 1bd2d42e6424..615cdbdd505f 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -8528,7 +8528,7 @@ ENOSYS for the others.
When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of
type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request.
-7.37 KVM_CAP_ARM_WRITABLE_IMP_ID_REGS
+7.42 KVM_CAP_ARM_WRITABLE_IMP_ID_REGS
-------------------------------------
:Architectures: arm64
@@ -8557,6 +8557,17 @@ given VM.
When this capability is enabled, KVM resets the VCPU when setting
MP_STATE_INIT_RECEIVED through IOCTL. The original MP_STATE is preserved.
+7.43 KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED
+-------------------------------------------
+
+:Architectures: arm64
+:Target: VM
+:Parameters: None
+
+This capability indicate to the userspace whether a PFNMAP memory region
+can be safely mapped as cacheable. This relies on the presence of
+force write back (FWB) feature support on the hardware.
+
8. Other capabilities.
======================
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index de2b4e9c9f9f..9fb8901dcd86 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -408,6 +408,13 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES:
r = BIT(0);
break;
+ case KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED:
+ if (!kvm)
+ r = -EINVAL;
+ else
+ r = kvm_arch_supports_cacheable_pfnmap();
+ break;
+
default:
r = 0;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index d00b85cb168c..ed9a46875a49 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -934,6 +934,7 @@ struct kvm_enable_cap {
#define KVM_CAP_ARM_EL2 240
#define KVM_CAP_ARM_EL2_E2H0 241
#define KVM_CAP_RISCV_MP_STATE_RESET 242
+#define KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED 243
struct kvm_irq_routing_irqchip {
__u32 irqchip;
--
2.34.1On Sat, Jun 21, 2025 at 04:21:11AM +0000, ankita@nvidia.com wrote: > From: Ankit Agrawal <ankita@nvidia.com> > > Introduce a new KVM capability to expose to the userspace whether > cacheable mapping of PFNMAP is supported. > > The ability to safely do the cacheable mapping of PFNMAP is contingent > on S2FWB and ARM64_HAS_CACHE_DIC. S2FWB allows KVM to avoid flushing > the D cache, ARM64_HAS_CACHE_DIC allows KVM to avoid flushing the icache > and turns icache_inval_pou() into a NOP. The cap would be false if > those requirements are missing and is checked by making use of > kvm_arch_supports_cacheable_pfnmap. > > This capability would allow userspace to discover the support. > It could for instance be used by userspace to prevent live-migration > across FWB and non-FWB hosts. > > CC: Catalin Marinas <catalin.marinas@arm.com> > CC: Jason Gunthorpe <jgg@nvidia.com> > CC: Oliver Upton <oliver.upton@linux.dev> > CC: David Hildenbrand <david@redhat.com> > Suggested-by: Marc Zyngier <maz@kernel.org> > Signed-off-by: Ankit Agrawal <ankita@nvidia.com> > --- > Documentation/virt/kvm/api.rst | 13 ++++++++++++- > arch/arm64/kvm/arm.c | 7 +++++++ > include/uapi/linux/kvm.h | 1 + > 3 files changed, 20 insertions(+), 1 deletion(-) I don't know if any VMM will ever use this, but it looks OK Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Jason
On 04.07.25 15:44, Jason Gunthorpe wrote: > On Sat, Jun 21, 2025 at 04:21:11AM +0000, ankita@nvidia.com wrote: >> From: Ankit Agrawal <ankita@nvidia.com> >> >> Introduce a new KVM capability to expose to the userspace whether >> cacheable mapping of PFNMAP is supported. >> >> The ability to safely do the cacheable mapping of PFNMAP is contingent >> on S2FWB and ARM64_HAS_CACHE_DIC. S2FWB allows KVM to avoid flushing >> the D cache, ARM64_HAS_CACHE_DIC allows KVM to avoid flushing the icache >> and turns icache_inval_pou() into a NOP. The cap would be false if >> those requirements are missing and is checked by making use of >> kvm_arch_supports_cacheable_pfnmap. >> >> This capability would allow userspace to discover the support. >> It could for instance be used by userspace to prevent live-migration >> across FWB and non-FWB hosts. >> >> CC: Catalin Marinas <catalin.marinas@arm.com> >> CC: Jason Gunthorpe <jgg@nvidia.com> >> CC: Oliver Upton <oliver.upton@linux.dev> >> CC: David Hildenbrand <david@redhat.com> >> Suggested-by: Marc Zyngier <maz@kernel.org> >> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> >> --- >> Documentation/virt/kvm/api.rst | 13 ++++++++++++- >> arch/arm64/kvm/arm.c | 7 +++++++ >> include/uapi/linux/kvm.h | 1 + >> 3 files changed, 20 insertions(+), 1 deletion(-) > > I don't know if any VMM will ever use this, but it looks OK So, should we defer it to the point where we actually have a use case? I mean, patch #4 could be simplified by modifying arm64 code in patch #5 only. No need for a common kvm_arch function etc. -- Cheers, David / dhildenb
On Fri, Jul 04, 2025 at 04:15:28PM +0200, David Hildenbrand wrote: > On 04.07.25 15:44, Jason Gunthorpe wrote: > > On Sat, Jun 21, 2025 at 04:21:11AM +0000, ankita@nvidia.com wrote: > > > From: Ankit Agrawal <ankita@nvidia.com> > > > > > > Introduce a new KVM capability to expose to the userspace whether > > > cacheable mapping of PFNMAP is supported. > > > > > > The ability to safely do the cacheable mapping of PFNMAP is contingent > > > on S2FWB and ARM64_HAS_CACHE_DIC. S2FWB allows KVM to avoid flushing > > > the D cache, ARM64_HAS_CACHE_DIC allows KVM to avoid flushing the icache > > > and turns icache_inval_pou() into a NOP. The cap would be false if > > > those requirements are missing and is checked by making use of > > > kvm_arch_supports_cacheable_pfnmap. > > > > > > This capability would allow userspace to discover the support. > > > It could for instance be used by userspace to prevent live-migration > > > across FWB and non-FWB hosts. > > > > > > CC: Catalin Marinas <catalin.marinas@arm.com> > > > CC: Jason Gunthorpe <jgg@nvidia.com> > > > CC: Oliver Upton <oliver.upton@linux.dev> > > > CC: David Hildenbrand <david@redhat.com> > > > Suggested-by: Marc Zyngier <maz@kernel.org> > > > Signed-off-by: Ankit Agrawal <ankita@nvidia.com> > > > --- > > > Documentation/virt/kvm/api.rst | 13 ++++++++++++- > > > arch/arm64/kvm/arm.c | 7 +++++++ > > > include/uapi/linux/kvm.h | 1 + > > > 3 files changed, 20 insertions(+), 1 deletion(-) > > > > I don't know if any VMM will ever use this, but it looks OK > > So, should we defer it to the point where we actually have a use case? > > I mean, patch #4 could be simplified by modifying arm64 code in patch #5 > only. No need for a common kvm_arch function etc. IDK, I think Marc and Oliver are right it makes sense to have it, I just don't really see how a VMM would make use of it.. Jason
© 2016 - 2025 Red Hat, Inc.