[kvmtool PATCH 0/2] arm64: Add MTE support

[kvmtool PATCH 0/2] arm64: Add MTE support

[Alexandru Elisei]

This series does what it says on the can: adds Memory Tagging Extension
(MTE) support in kvmtool.

Alexandru Elisei (2):
  update_headers: Sync ABI headers with Linux v5.17-rc8
  aarch64: Add support for MTE

 arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
 arm/aarch64/include/asm/kvm.h             |  5 +++++
 arm/aarch64/include/kvm/kvm-arch.h        |  1 +
 arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
 arm/aarch64/kvm.c                         | 13 +++++++++++++
 arm/include/arm-common/kvm-config-arch.h  |  1 +
 arm/kvm.c                                 |  3 +++
 include/linux/kvm.h                       | 18 ++++++++++++++++++
 x86/include/asm/kvm.h                     | 19 ++++++++++++++++++-
 9 files changed, 64 insertions(+), 1 deletion(-)

-- 
2.35.1

[kvmtool PATCH 0/2] arm64: Add MTE support

[Alexandru Elisei]

This series does what it says on the can: adds Memory Tagging Extension
(MTE) support in kvmtool.

Alexandru Elisei (2):
  update_headers: Sync ABI headers with Linux v5.17-rc8
  aarch64: Add support for MTE

 arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
 arm/aarch64/include/asm/kvm.h             |  5 +++++
 arm/aarch64/include/kvm/kvm-arch.h        |  1 +
 arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
 arm/aarch64/kvm.c                         | 13 +++++++++++++
 arm/include/arm-common/kvm-config-arch.h  |  1 +
 arm/kvm.c                                 |  3 +++
 include/linux/kvm.h                       | 18 ++++++++++++++++++
 x86/include/asm/kvm.h                     | 19 ++++++++++++++++++-
 9 files changed, 64 insertions(+), 1 deletion(-)

-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[kvmtool PATCH 1/2] update_headers: Sync ABI headers with Linux v5.17-rc8

[Alexandru Elisei]

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arm/aarch64/include/asm/kvm.h |  5 +++++
 include/linux/kvm.h           | 18 ++++++++++++++++++
 x86/include/asm/kvm.h         | 19 ++++++++++++++++++-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/arm/aarch64/include/asm/kvm.h b/arm/aarch64/include/asm/kvm.h
index b3edde68bc3e..323e251ed37b 100644
--- a/arm/aarch64/include/asm/kvm.h
+++ b/arm/aarch64/include/asm/kvm.h
@@ -281,6 +281,11 @@ struct kvm_arm_copy_mte_tags {
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED	3
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED     	(1U << 4)
 
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3	KVM_REG_ARM_FW_REG(3)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_AVAIL		0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_AVAIL		1
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_REQUIRED	2
+
 /* SVE registers */
 #define KVM_REG_ARM64_SVE		(0x15 << KVM_REG_ARM_COPROC_SHIFT)
 
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 1daa45268de2..507ee1f2aa96 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -1131,6 +1131,10 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
 #define KVM_CAP_ARM_MTE 205
 #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206
+#define KVM_CAP_VM_GPA_BITS 207
+#define KVM_CAP_XSAVE2 208
+#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_PPC_AIL_MODE_3 210
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1162,11 +1166,20 @@ struct kvm_irq_routing_hv_sint {
 	__u32 sint;
 };
 
+struct kvm_irq_routing_xen_evtchn {
+	__u32 port;
+	__u32 vcpu;
+	__u32 priority;
+};
+
+#define KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL ((__u32)(-1))
+
 /* gsi routing entry types */
 #define KVM_IRQ_ROUTING_IRQCHIP 1
 #define KVM_IRQ_ROUTING_MSI 2
 #define KVM_IRQ_ROUTING_S390_ADAPTER 3
 #define KVM_IRQ_ROUTING_HV_SINT 4
+#define KVM_IRQ_ROUTING_XEN_EVTCHN 5
 
 struct kvm_irq_routing_entry {
 	__u32 gsi;
@@ -1178,6 +1191,7 @@ struct kvm_irq_routing_entry {
 		struct kvm_irq_routing_msi msi;
 		struct kvm_irq_routing_s390_adapter adapter;
 		struct kvm_irq_routing_hv_sint hv_sint;
+		struct kvm_irq_routing_xen_evtchn xen_evtchn;
 		__u32 pad[8];
 	} u;
 };
@@ -1208,6 +1222,7 @@ struct kvm_x86_mce {
 #define KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL	(1 << 1)
 #define KVM_XEN_HVM_CONFIG_SHARED_INFO		(1 << 2)
 #define KVM_XEN_HVM_CONFIG_RUNSTATE		(1 << 3)
+#define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL	(1 << 4)
 
 struct kvm_xen_hvm_config {
 	__u32 flags;
@@ -2031,4 +2046,7 @@ struct kvm_stats_desc {
 
 #define KVM_GET_STATS_FD  _IO(KVMIO,  0xce)
 
+/* Available with KVM_CAP_XSAVE2 */
+#define KVM_GET_XSAVE2		  _IOR(KVMIO,  0xcf, struct kvm_xsave)
+
 #endif /* __LINUX_KVM_H */
diff --git a/x86/include/asm/kvm.h b/x86/include/asm/kvm.h
index 5a776a08f78c..bf6e96011dfe 100644
--- a/x86/include/asm/kvm.h
+++ b/x86/include/asm/kvm.h
@@ -373,9 +373,23 @@ struct kvm_debugregs {
 	__u64 reserved[9];
 };
 
-/* for KVM_CAP_XSAVE */
+/* for KVM_CAP_XSAVE and KVM_CAP_XSAVE2 */
 struct kvm_xsave {
+	/*
+	 * KVM_GET_XSAVE2 and KVM_SET_XSAVE write and read as many bytes
+	 * as are returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2)
+	 * respectively, when invoked on the vm file descriptor.
+	 *
+	 * The size value returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2)
+	 * will always be at least 4096. Currently, it is only greater
+	 * than 4096 if a dynamic feature has been enabled with
+	 * ``arch_prctl()``, but this may change in the future.
+	 *
+	 * The offsets of the state save areas in struct kvm_xsave follow
+	 * the contents of CPUID leaf 0xD on the host.
+	 */
 	__u32 region[1024];
+	__u32 extra[0];
 };
 
 #define KVM_MAX_XCRS	16
@@ -438,6 +452,9 @@ struct kvm_sync_regs {
 
 #define KVM_STATE_VMX_PREEMPTION_TIMER_DEADLINE	0x00000001
 
+/* attributes for system fd (group 0) */
+#define KVM_X86_XCOMP_GUEST_SUPP	0
+
 struct kvm_vmx_nested_state_data {
 	__u8 vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
 	__u8 shadow_vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
-- 
2.35.1

[kvmtool PATCH 1/2] update_headers: Sync ABI headers with Linux v5.17-rc8

[Alexandru Elisei]

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arm/aarch64/include/asm/kvm.h |  5 +++++
 include/linux/kvm.h           | 18 ++++++++++++++++++
 x86/include/asm/kvm.h         | 19 ++++++++++++++++++-
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/arm/aarch64/include/asm/kvm.h b/arm/aarch64/include/asm/kvm.h
index b3edde68bc3e..323e251ed37b 100644
--- a/arm/aarch64/include/asm/kvm.h
+++ b/arm/aarch64/include/asm/kvm.h
@@ -281,6 +281,11 @@ struct kvm_arm_copy_mte_tags {
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED	3
 #define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED     	(1U << 4)
 
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3	KVM_REG_ARM_FW_REG(3)
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_AVAIL		0
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_AVAIL		1
+#define KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_3_NOT_REQUIRED	2
+
 /* SVE registers */
 #define KVM_REG_ARM64_SVE		(0x15 << KVM_REG_ARM_COPROC_SHIFT)
 
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 1daa45268de2..507ee1f2aa96 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -1131,6 +1131,10 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_EXIT_ON_EMULATION_FAILURE 204
 #define KVM_CAP_ARM_MTE 205
 #define KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM 206
+#define KVM_CAP_VM_GPA_BITS 207
+#define KVM_CAP_XSAVE2 208
+#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_PPC_AIL_MODE_3 210
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -1162,11 +1166,20 @@ struct kvm_irq_routing_hv_sint {
 	__u32 sint;
 };
 
+struct kvm_irq_routing_xen_evtchn {
+	__u32 port;
+	__u32 vcpu;
+	__u32 priority;
+};
+
+#define KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL ((__u32)(-1))
+
 /* gsi routing entry types */
 #define KVM_IRQ_ROUTING_IRQCHIP 1
 #define KVM_IRQ_ROUTING_MSI 2
 #define KVM_IRQ_ROUTING_S390_ADAPTER 3
 #define KVM_IRQ_ROUTING_HV_SINT 4
+#define KVM_IRQ_ROUTING_XEN_EVTCHN 5
 
 struct kvm_irq_routing_entry {
 	__u32 gsi;
@@ -1178,6 +1191,7 @@ struct kvm_irq_routing_entry {
 		struct kvm_irq_routing_msi msi;
 		struct kvm_irq_routing_s390_adapter adapter;
 		struct kvm_irq_routing_hv_sint hv_sint;
+		struct kvm_irq_routing_xen_evtchn xen_evtchn;
 		__u32 pad[8];
 	} u;
 };
@@ -1208,6 +1222,7 @@ struct kvm_x86_mce {
 #define KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL	(1 << 1)
 #define KVM_XEN_HVM_CONFIG_SHARED_INFO		(1 << 2)
 #define KVM_XEN_HVM_CONFIG_RUNSTATE		(1 << 3)
+#define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL	(1 << 4)
 
 struct kvm_xen_hvm_config {
 	__u32 flags;
@@ -2031,4 +2046,7 @@ struct kvm_stats_desc {
 
 #define KVM_GET_STATS_FD  _IO(KVMIO,  0xce)
 
+/* Available with KVM_CAP_XSAVE2 */
+#define KVM_GET_XSAVE2		  _IOR(KVMIO,  0xcf, struct kvm_xsave)
+
 #endif /* __LINUX_KVM_H */
diff --git a/x86/include/asm/kvm.h b/x86/include/asm/kvm.h
index 5a776a08f78c..bf6e96011dfe 100644
--- a/x86/include/asm/kvm.h
+++ b/x86/include/asm/kvm.h
@@ -373,9 +373,23 @@ struct kvm_debugregs {
 	__u64 reserved[9];
 };
 
-/* for KVM_CAP_XSAVE */
+/* for KVM_CAP_XSAVE and KVM_CAP_XSAVE2 */
 struct kvm_xsave {
+	/*
+	 * KVM_GET_XSAVE2 and KVM_SET_XSAVE write and read as many bytes
+	 * as are returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2)
+	 * respectively, when invoked on the vm file descriptor.
+	 *
+	 * The size value returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2)
+	 * will always be at least 4096. Currently, it is only greater
+	 * than 4096 if a dynamic feature has been enabled with
+	 * ``arch_prctl()``, but this may change in the future.
+	 *
+	 * The offsets of the state save areas in struct kvm_xsave follow
+	 * the contents of CPUID leaf 0xD on the host.
+	 */
 	__u32 region[1024];
+	__u32 extra[0];
 };
 
 #define KVM_MAX_XCRS	16
@@ -438,6 +452,9 @@ struct kvm_sync_regs {
 
 #define KVM_STATE_VMX_PREEMPTION_TIMER_DEADLINE	0x00000001
 
+/* attributes for system fd (group 0) */
+#define KVM_X86_XCOMP_GUEST_SUPP	0
+
 struct kvm_vmx_nested_state_data {
 	__u8 vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
 	__u8 shadow_vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
 arm/aarch64/include/kvm/kvm-arch.h        |  1 +
 arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
 arm/aarch64/kvm.c                         | 13 +++++++++++++
 arm/include/arm-common/kvm-config-arch.h  |  1 +
 arm/kvm.c                                 |  3 +++
 6 files changed, 23 insertions(+)

diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
index bee2fc255a82..5616b27e257e 100644
--- a/arm/aarch32/include/kvm/kvm-arch.h
+++ b/arm/aarch32/include/kvm/kvm-arch.h
@@ -5,6 +5,9 @@
 
 #define kvm__arch_get_kern_offset(...)	0x8000
 
+struct kvm;
+static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
+
 #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
 
 #define MAX_PAGE_SIZE	SZ_4K
diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
index 5e5ee41211ed..9124f6919d0f 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -6,6 +6,7 @@
 struct kvm;
 unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
 int kvm__arch_get_ipa_limit(struct kvm *kvm);
+void kvm__arch_enable_mte(struct kvm *kvm);
 
 #define ARM_MAX_MEMORY(kvm)	({					\
 	u64 max_ram;							\
diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
index 04be43dfa9b2..11250365d8d5 100644
--- a/arm/aarch64/include/kvm/kvm-config-arch.h
+++ b/arm/aarch64/include/kvm/kvm-config-arch.h
@@ -6,6 +6,8 @@
 			"Run AArch32 guest"),				\
 	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
 			"Create PMUv3 device"),				\
+	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
+			"Enable memory tagging extension"),		\
 	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
 			"Specify random seed for Kernel Address Space "	\
 			"Layout Randomization (KASLR)"),
diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
index 56a0aedc263d..46548f8ee96e 100644
--- a/arm/aarch64/kvm.c
+++ b/arm/aarch64/kvm.c
@@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
 
 	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
 }
+
+void kvm__arch_enable_mte(struct kvm *kvm)
+{
+	struct kvm_enable_cap cap = {
+		.cap = KVM_CAP_ARM_MTE,
+	};
+
+	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
+		die("MTE capability is not supported");
+
+	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
+		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
+}
diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
index 5734c46ab9e6..16e8d500a71b 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -9,6 +9,7 @@ struct kvm_config_arch {
 	bool		virtio_trans_pci;
 	bool		aarch32_guest;
 	bool		has_pmuv3;
+	bool		has_mte;
 	u64		kaslr_seed;
 	enum irqchip_type irqchip;
 	u64		fw_addr;
diff --git a/arm/kvm.c b/arm/kvm.c
index 80d233f13d0b..f2db93953778 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
 	/* Create the virtual GIC. */
 	if (gic__create(kvm, kvm->cfg.arch.irqchip))
 		die("Failed to create virtual GIC");
+
+	if (kvm->cfg.arch.has_mte)
+		kvm__arch_enable_mte(kvm);
 }
 
 #define FDT_ALIGN	SZ_2M
-- 
2.35.1

[kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
 arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
 arm/aarch64/include/kvm/kvm-arch.h        |  1 +
 arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
 arm/aarch64/kvm.c                         | 13 +++++++++++++
 arm/include/arm-common/kvm-config-arch.h  |  1 +
 arm/kvm.c                                 |  3 +++
 6 files changed, 23 insertions(+)

diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
index bee2fc255a82..5616b27e257e 100644
--- a/arm/aarch32/include/kvm/kvm-arch.h
+++ b/arm/aarch32/include/kvm/kvm-arch.h
@@ -5,6 +5,9 @@
 
 #define kvm__arch_get_kern_offset(...)	0x8000
 
+struct kvm;
+static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
+
 #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
 
 #define MAX_PAGE_SIZE	SZ_4K
diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
index 5e5ee41211ed..9124f6919d0f 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -6,6 +6,7 @@
 struct kvm;
 unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
 int kvm__arch_get_ipa_limit(struct kvm *kvm);
+void kvm__arch_enable_mte(struct kvm *kvm);
 
 #define ARM_MAX_MEMORY(kvm)	({					\
 	u64 max_ram;							\
diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
index 04be43dfa9b2..11250365d8d5 100644
--- a/arm/aarch64/include/kvm/kvm-config-arch.h
+++ b/arm/aarch64/include/kvm/kvm-config-arch.h
@@ -6,6 +6,8 @@
 			"Run AArch32 guest"),				\
 	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
 			"Create PMUv3 device"),				\
+	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
+			"Enable memory tagging extension"),		\
 	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
 			"Specify random seed for Kernel Address Space "	\
 			"Layout Randomization (KASLR)"),
diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
index 56a0aedc263d..46548f8ee96e 100644
--- a/arm/aarch64/kvm.c
+++ b/arm/aarch64/kvm.c
@@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
 
 	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
 }
+
+void kvm__arch_enable_mte(struct kvm *kvm)
+{
+	struct kvm_enable_cap cap = {
+		.cap = KVM_CAP_ARM_MTE,
+	};
+
+	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
+		die("MTE capability is not supported");
+
+	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
+		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
+}
diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
index 5734c46ab9e6..16e8d500a71b 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -9,6 +9,7 @@ struct kvm_config_arch {
 	bool		virtio_trans_pci;
 	bool		aarch32_guest;
 	bool		has_pmuv3;
+	bool		has_mte;
 	u64		kaslr_seed;
 	enum irqchip_type irqchip;
 	u64		fw_addr;
diff --git a/arm/kvm.c b/arm/kvm.c
index 80d233f13d0b..f2db93953778 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
 	/* Create the virtual GIC. */
 	if (gic__create(kvm, kvm->cfg.arch.irqchip))
 		die("Failed to create virtual GIC");
+
+	if (kvm->cfg.arch.has_mte)
+		kvm__arch_enable_mte(kvm);
 }
 
 #define FDT_ALIGN	SZ_2M
-- 
2.35.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

Hi Alexandru,

On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> 
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>  arm/aarch64/kvm.c                         | 13 +++++++++++++
>  arm/include/arm-common/kvm-config-arch.h  |  1 +
>  arm/kvm.c                                 |  3 +++
>  6 files changed, 23 insertions(+)
> 
> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> index bee2fc255a82..5616b27e257e 100644
> --- a/arm/aarch32/include/kvm/kvm-arch.h
> +++ b/arm/aarch32/include/kvm/kvm-arch.h
> @@ -5,6 +5,9 @@
>  
>  #define kvm__arch_get_kern_offset(...)	0x8000
>  
> +struct kvm;
> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> +
>  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>  
>  #define MAX_PAGE_SIZE	SZ_4K
> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> index 5e5ee41211ed..9124f6919d0f 100644
> --- a/arm/aarch64/include/kvm/kvm-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-arch.h
> @@ -6,6 +6,7 @@
>  struct kvm;
>  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>  int kvm__arch_get_ipa_limit(struct kvm *kvm);
> +void kvm__arch_enable_mte(struct kvm *kvm);
>  
>  #define ARM_MAX_MEMORY(kvm)	({					\
>  	u64 max_ram;							\
> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> index 04be43dfa9b2..11250365d8d5 100644
> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> @@ -6,6 +6,8 @@
>  			"Run AArch32 guest"),				\
>  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>  			"Create PMUv3 device"),				\
> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> +			"Enable memory tagging extension"),		\
>  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>  			"Specify random seed for Kernel Address Space "	\
>  			"Layout Randomization (KASLR)"),
> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> index 56a0aedc263d..46548f8ee96e 100644
> --- a/arm/aarch64/kvm.c
> +++ b/arm/aarch64/kvm.c
> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>  
>  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>  }
> +
> +void kvm__arch_enable_mte(struct kvm *kvm)
> +{
> +	struct kvm_enable_cap cap = {
> +		.cap = KVM_CAP_ARM_MTE,
> +	};
> +
> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> +		die("MTE capability is not supported");
> +
> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> +}
> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> index 5734c46ab9e6..16e8d500a71b 100644
> --- a/arm/include/arm-common/kvm-config-arch.h
> +++ b/arm/include/arm-common/kvm-config-arch.h
> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>  	bool		virtio_trans_pci;
>  	bool		aarch32_guest;
>  	bool		has_pmuv3;
> +	bool		has_mte;
>  	u64		kaslr_seed;
>  	enum irqchip_type irqchip;
>  	u64		fw_addr;
> diff --git a/arm/kvm.c b/arm/kvm.c
> index 80d233f13d0b..f2db93953778 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>  	/* Create the virtual GIC. */
>  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>  		die("Failed to create virtual GIC");
> +
> +	if (kvm->cfg.arch.has_mte)
> +		kvm__arch_enable_mte(kvm);
>  }

Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
PAC and SVE?

Cheers
Vladimir

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

Hi Alexandru,

On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> 
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> ---
>  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>  arm/aarch64/kvm.c                         | 13 +++++++++++++
>  arm/include/arm-common/kvm-config-arch.h  |  1 +
>  arm/kvm.c                                 |  3 +++
>  6 files changed, 23 insertions(+)
> 
> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> index bee2fc255a82..5616b27e257e 100644
> --- a/arm/aarch32/include/kvm/kvm-arch.h
> +++ b/arm/aarch32/include/kvm/kvm-arch.h
> @@ -5,6 +5,9 @@
>  
>  #define kvm__arch_get_kern_offset(...)	0x8000
>  
> +struct kvm;
> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> +
>  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>  
>  #define MAX_PAGE_SIZE	SZ_4K
> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> index 5e5ee41211ed..9124f6919d0f 100644
> --- a/arm/aarch64/include/kvm/kvm-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-arch.h
> @@ -6,6 +6,7 @@
>  struct kvm;
>  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>  int kvm__arch_get_ipa_limit(struct kvm *kvm);
> +void kvm__arch_enable_mte(struct kvm *kvm);
>  
>  #define ARM_MAX_MEMORY(kvm)	({					\
>  	u64 max_ram;							\
> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> index 04be43dfa9b2..11250365d8d5 100644
> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> @@ -6,6 +6,8 @@
>  			"Run AArch32 guest"),				\
>  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>  			"Create PMUv3 device"),				\
> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> +			"Enable memory tagging extension"),		\
>  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>  			"Specify random seed for Kernel Address Space "	\
>  			"Layout Randomization (KASLR)"),
> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> index 56a0aedc263d..46548f8ee96e 100644
> --- a/arm/aarch64/kvm.c
> +++ b/arm/aarch64/kvm.c
> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>  
>  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>  }
> +
> +void kvm__arch_enable_mte(struct kvm *kvm)
> +{
> +	struct kvm_enable_cap cap = {
> +		.cap = KVM_CAP_ARM_MTE,
> +	};
> +
> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> +		die("MTE capability is not supported");
> +
> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> +}
> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> index 5734c46ab9e6..16e8d500a71b 100644
> --- a/arm/include/arm-common/kvm-config-arch.h
> +++ b/arm/include/arm-common/kvm-config-arch.h
> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>  	bool		virtio_trans_pci;
>  	bool		aarch32_guest;
>  	bool		has_pmuv3;
> +	bool		has_mte;
>  	u64		kaslr_seed;
>  	enum irqchip_type irqchip;
>  	u64		fw_addr;
> diff --git a/arm/kvm.c b/arm/kvm.c
> index 80d233f13d0b..f2db93953778 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>  	/* Create the virtual GIC. */
>  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>  		die("Failed to create virtual GIC");
> +
> +	if (kvm->cfg.arch.has_mte)
> +		kvm__arch_enable_mte(kvm);
>  }

Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
PAC and SVE?

Cheers
Vladimir

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> Hi Alexandru,
> 
> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> > MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> > Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> > 
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> >  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> >  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> >  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> >  arm/aarch64/kvm.c                         | 13 +++++++++++++
> >  arm/include/arm-common/kvm-config-arch.h  |  1 +
> >  arm/kvm.c                                 |  3 +++
> >  6 files changed, 23 insertions(+)
> > 
> > diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> > index bee2fc255a82..5616b27e257e 100644
> > --- a/arm/aarch32/include/kvm/kvm-arch.h
> > +++ b/arm/aarch32/include/kvm/kvm-arch.h
> > @@ -5,6 +5,9 @@
> >  
> >  #define kvm__arch_get_kern_offset(...)	0x8000
> >  
> > +struct kvm;
> > +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> > +
> >  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
> >  
> >  #define MAX_PAGE_SIZE	SZ_4K
> > diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> > index 5e5ee41211ed..9124f6919d0f 100644
> > --- a/arm/aarch64/include/kvm/kvm-arch.h
> > +++ b/arm/aarch64/include/kvm/kvm-arch.h
> > @@ -6,6 +6,7 @@
> >  struct kvm;
> >  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
> >  int kvm__arch_get_ipa_limit(struct kvm *kvm);
> > +void kvm__arch_enable_mte(struct kvm *kvm);
> >  
> >  #define ARM_MAX_MEMORY(kvm)	({					\
> >  	u64 max_ram;							\
> > diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> > index 04be43dfa9b2..11250365d8d5 100644
> > --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> > +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> > @@ -6,6 +6,8 @@
> >  			"Run AArch32 guest"),				\
> >  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
> >  			"Create PMUv3 device"),				\
> > +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> > +			"Enable memory tagging extension"),		\
> >  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
> >  			"Specify random seed for Kernel Address Space "	\
> >  			"Layout Randomization (KASLR)"),
> > diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> > index 56a0aedc263d..46548f8ee96e 100644
> > --- a/arm/aarch64/kvm.c
> > +++ b/arm/aarch64/kvm.c
> > @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> >  
> >  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> >  }
> > +
> > +void kvm__arch_enable_mte(struct kvm *kvm)
> > +{
> > +	struct kvm_enable_cap cap = {
> > +		.cap = KVM_CAP_ARM_MTE,
> > +	};
> > +
> > +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> > +		die("MTE capability is not supported");
> > +
> > +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> > +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> > +}
> > diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> > index 5734c46ab9e6..16e8d500a71b 100644
> > --- a/arm/include/arm-common/kvm-config-arch.h
> > +++ b/arm/include/arm-common/kvm-config-arch.h
> > @@ -9,6 +9,7 @@ struct kvm_config_arch {
> >  	bool		virtio_trans_pci;
> >  	bool		aarch32_guest;
> >  	bool		has_pmuv3;
> > +	bool		has_mte;
> >  	u64		kaslr_seed;
> >  	enum irqchip_type irqchip;
> >  	u64		fw_addr;
> > diff --git a/arm/kvm.c b/arm/kvm.c
> > index 80d233f13d0b..f2db93953778 100644
> > --- a/arm/kvm.c
> > +++ b/arm/kvm.c
> > @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
> >  	/* Create the virtual GIC. */
> >  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
> >  		die("Failed to create virtual GIC");
> > +
> > +	if (kvm->cfg.arch.has_mte)
> > +		kvm__arch_enable_mte(kvm);
> >  }
> 
> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> PAC and SVE?

I thought about that, the reason I chose to enable it based a kvmtool
command line option, instead of always being enabled if available, is
because of the overhead of sanitising the MTE tags on each stage 2 data
abort. Steven, am I overreacting and that overhead is negligible?

Also, as far as I know, PAC and SVE incur basically no overhead in KVM
until the guest starts to use those features.

Do you have a specific reason for wanting MTE to always be enabled if
available? I'm happy to be convinced to make MTE enabled by default, I
don't have preference either way.

Thanks,
Alex

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> Hi Alexandru,
> 
> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> > MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> > Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> > 
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> >  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> >  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> >  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> >  arm/aarch64/kvm.c                         | 13 +++++++++++++
> >  arm/include/arm-common/kvm-config-arch.h  |  1 +
> >  arm/kvm.c                                 |  3 +++
> >  6 files changed, 23 insertions(+)
> > 
> > diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> > index bee2fc255a82..5616b27e257e 100644
> > --- a/arm/aarch32/include/kvm/kvm-arch.h
> > +++ b/arm/aarch32/include/kvm/kvm-arch.h
> > @@ -5,6 +5,9 @@
> >  
> >  #define kvm__arch_get_kern_offset(...)	0x8000
> >  
> > +struct kvm;
> > +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> > +
> >  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
> >  
> >  #define MAX_PAGE_SIZE	SZ_4K
> > diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> > index 5e5ee41211ed..9124f6919d0f 100644
> > --- a/arm/aarch64/include/kvm/kvm-arch.h
> > +++ b/arm/aarch64/include/kvm/kvm-arch.h
> > @@ -6,6 +6,7 @@
> >  struct kvm;
> >  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
> >  int kvm__arch_get_ipa_limit(struct kvm *kvm);
> > +void kvm__arch_enable_mte(struct kvm *kvm);
> >  
> >  #define ARM_MAX_MEMORY(kvm)	({					\
> >  	u64 max_ram;							\
> > diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> > index 04be43dfa9b2..11250365d8d5 100644
> > --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> > +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> > @@ -6,6 +6,8 @@
> >  			"Run AArch32 guest"),				\
> >  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
> >  			"Create PMUv3 device"),				\
> > +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> > +			"Enable memory tagging extension"),		\
> >  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
> >  			"Specify random seed for Kernel Address Space "	\
> >  			"Layout Randomization (KASLR)"),
> > diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> > index 56a0aedc263d..46548f8ee96e 100644
> > --- a/arm/aarch64/kvm.c
> > +++ b/arm/aarch64/kvm.c
> > @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> >  
> >  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> >  }
> > +
> > +void kvm__arch_enable_mte(struct kvm *kvm)
> > +{
> > +	struct kvm_enable_cap cap = {
> > +		.cap = KVM_CAP_ARM_MTE,
> > +	};
> > +
> > +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> > +		die("MTE capability is not supported");
> > +
> > +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> > +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> > +}
> > diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> > index 5734c46ab9e6..16e8d500a71b 100644
> > --- a/arm/include/arm-common/kvm-config-arch.h
> > +++ b/arm/include/arm-common/kvm-config-arch.h
> > @@ -9,6 +9,7 @@ struct kvm_config_arch {
> >  	bool		virtio_trans_pci;
> >  	bool		aarch32_guest;
> >  	bool		has_pmuv3;
> > +	bool		has_mte;
> >  	u64		kaslr_seed;
> >  	enum irqchip_type irqchip;
> >  	u64		fw_addr;
> > diff --git a/arm/kvm.c b/arm/kvm.c
> > index 80d233f13d0b..f2db93953778 100644
> > --- a/arm/kvm.c
> > +++ b/arm/kvm.c
> > @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
> >  	/* Create the virtual GIC. */
> >  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
> >  		die("Failed to create virtual GIC");
> > +
> > +	if (kvm->cfg.arch.has_mte)
> > +		kvm__arch_enable_mte(kvm);
> >  }
> 
> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> PAC and SVE?

I thought about that, the reason I chose to enable it based a kvmtool
command line option, instead of always being enabled if available, is
because of the overhead of sanitising the MTE tags on each stage 2 data
abort. Steven, am I overreacting and that overhead is negligible?

Also, as far as I know, PAC and SVE incur basically no overhead in KVM
until the guest starts to use those features.

Do you have a specific reason for wanting MTE to always be enabled if
available? I'm happy to be convinced to make MTE enabled by default, I
don't have preference either way.

Thanks,
Alex

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Steven Price]

On 21/03/2022 17:08, Alexandru Elisei wrote:
> Hi,
> 
> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>> Hi Alexandru,
>>
>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>
>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>> ---
>>>  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>  arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>  arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>  arm/kvm.c                                 |  3 +++
>>>  6 files changed, 23 insertions(+)
>>>
>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>> index bee2fc255a82..5616b27e257e 100644
>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>> @@ -5,6 +5,9 @@
>>>  
>>>  #define kvm__arch_get_kern_offset(...)	0x8000
>>>  
>>> +struct kvm;
>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>> +
>>>  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>  
>>>  #define MAX_PAGE_SIZE	SZ_4K
>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>> index 5e5ee41211ed..9124f6919d0f 100644
>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>> @@ -6,6 +6,7 @@
>>>  struct kvm;
>>>  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>  int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>  
>>>  #define ARM_MAX_MEMORY(kvm)	({					\
>>>  	u64 max_ram;							\
>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> index 04be43dfa9b2..11250365d8d5 100644
>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> @@ -6,6 +6,8 @@
>>>  			"Run AArch32 guest"),				\
>>>  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>  			"Create PMUv3 device"),				\
>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>> +			"Enable memory tagging extension"),		\
>>>  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>  			"Specify random seed for Kernel Address Space "	\
>>>  			"Layout Randomization (KASLR)"),
>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>> index 56a0aedc263d..46548f8ee96e 100644
>>> --- a/arm/aarch64/kvm.c
>>> +++ b/arm/aarch64/kvm.c
>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>  
>>>  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>  }
>>> +
>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>> +{
>>> +	struct kvm_enable_cap cap = {
>>> +		.cap = KVM_CAP_ARM_MTE,
>>> +	};
>>> +
>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>> +		die("MTE capability is not supported");
>>> +
>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>> +}
>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>> index 5734c46ab9e6..16e8d500a71b 100644
>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>  	bool		virtio_trans_pci;
>>>  	bool		aarch32_guest;
>>>  	bool		has_pmuv3;
>>> +	bool		has_mte;
>>>  	u64		kaslr_seed;
>>>  	enum irqchip_type irqchip;
>>>  	u64		fw_addr;
>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>> index 80d233f13d0b..f2db93953778 100644
>>> --- a/arm/kvm.c
>>> +++ b/arm/kvm.c
>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>  	/* Create the virtual GIC. */
>>>  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>  		die("Failed to create virtual GIC");
>>> +
>>> +	if (kvm->cfg.arch.has_mte)
>>> +		kvm__arch_enable_mte(kvm);
>>>  }
>>
>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>> PAC and SVE?
> 
> I thought about that, the reason I chose to enable it based a kvmtool
> command line option, instead of always being enabled if available, is
> because of the overhead of sanitising the MTE tags on each stage 2 data
> abort. Steven, am I overreacting and that overhead is negligible?

I don't have any figures from hardware I'm afraid, so I can't say what
the actual time overhead is in reality (but I suspect it's measurable).

However there is also a memory overhead when it comes to swapping MTE
tagged memory out. The tags have to be stored somewhere (currently they
remain in memory) so there's >3% overhead[1] in terms of memory when
swapped out.

So I think probably the opt-in approach makes sense, but I've no strong
feelings and I can see the benefits for the default being "every available".

Steve

[1] For each 4k page a 128 byte buffer is allocated for the pages
(3.125% overhead), but on top of that there's the kmalloc overhead and
an Xarray to store the pointer in. I haven't done the maths but it
probably comes out closer to 4%.

> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> until the guest starts to use those features.
> 
> Do you have a specific reason for wanting MTE to always be enabled if
> available? I'm happy to be convinced to make MTE enabled by default, I
> don't have preference either way.
> 
> Thanks,
> Alex

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Steven Price]

On 21/03/2022 17:08, Alexandru Elisei wrote:
> Hi,
> 
> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>> Hi Alexandru,
>>
>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>
>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>> ---
>>>  arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>  arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>  arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>  arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>  arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>  arm/kvm.c                                 |  3 +++
>>>  6 files changed, 23 insertions(+)
>>>
>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>> index bee2fc255a82..5616b27e257e 100644
>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>> @@ -5,6 +5,9 @@
>>>  
>>>  #define kvm__arch_get_kern_offset(...)	0x8000
>>>  
>>> +struct kvm;
>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>> +
>>>  #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>  
>>>  #define MAX_PAGE_SIZE	SZ_4K
>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>> index 5e5ee41211ed..9124f6919d0f 100644
>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>> @@ -6,6 +6,7 @@
>>>  struct kvm;
>>>  unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>  int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>  
>>>  #define ARM_MAX_MEMORY(kvm)	({					\
>>>  	u64 max_ram;							\
>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> index 04be43dfa9b2..11250365d8d5 100644
>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> @@ -6,6 +6,8 @@
>>>  			"Run AArch32 guest"),				\
>>>  	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>  			"Create PMUv3 device"),				\
>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>> +			"Enable memory tagging extension"),		\
>>>  	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>  			"Specify random seed for Kernel Address Space "	\
>>>  			"Layout Randomization (KASLR)"),
>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>> index 56a0aedc263d..46548f8ee96e 100644
>>> --- a/arm/aarch64/kvm.c
>>> +++ b/arm/aarch64/kvm.c
>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>  
>>>  	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>  }
>>> +
>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>> +{
>>> +	struct kvm_enable_cap cap = {
>>> +		.cap = KVM_CAP_ARM_MTE,
>>> +	};
>>> +
>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>> +		die("MTE capability is not supported");
>>> +
>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>> +}
>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>> index 5734c46ab9e6..16e8d500a71b 100644
>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>  	bool		virtio_trans_pci;
>>>  	bool		aarch32_guest;
>>>  	bool		has_pmuv3;
>>> +	bool		has_mte;
>>>  	u64		kaslr_seed;
>>>  	enum irqchip_type irqchip;
>>>  	u64		fw_addr;
>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>> index 80d233f13d0b..f2db93953778 100644
>>> --- a/arm/kvm.c
>>> +++ b/arm/kvm.c
>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>  	/* Create the virtual GIC. */
>>>  	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>  		die("Failed to create virtual GIC");
>>> +
>>> +	if (kvm->cfg.arch.has_mte)
>>> +		kvm__arch_enable_mte(kvm);
>>>  }
>>
>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>> PAC and SVE?
> 
> I thought about that, the reason I chose to enable it based a kvmtool
> command line option, instead of always being enabled if available, is
> because of the overhead of sanitising the MTE tags on each stage 2 data
> abort. Steven, am I overreacting and that overhead is negligible?

I don't have any figures from hardware I'm afraid, so I can't say what
the actual time overhead is in reality (but I suspect it's measurable).

However there is also a memory overhead when it comes to swapping MTE
tagged memory out. The tags have to be stored somewhere (currently they
remain in memory) so there's >3% overhead[1] in terms of memory when
swapped out.

So I think probably the opt-in approach makes sense, but I've no strong
feelings and I can see the benefits for the default being "every available".

Steve

[1] For each 4k page a 128 byte buffer is allocated for the pages
(3.125% overhead), but on top of that there's the kmalloc overhead and
an Xarray to store the pointer in. I haven't done the maths but it
probably comes out closer to 4%.

> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> until the guest starts to use those features.
> 
> Do you have a specific reason for wanting MTE to always be enabled if
> available? I'm happy to be convinced to make MTE enabled by default, I
> don't have preference either way.
> 
> Thanks,
> Alex


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> Hi,
> 
> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>> Hi Alexandru,
>>
>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>
>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>> ---
>>>   arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>   arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>   arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>   arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>   arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>   arm/kvm.c                                 |  3 +++
>>>   6 files changed, 23 insertions(+)
>>>
>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>> index bee2fc255a82..5616b27e257e 100644
>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>> @@ -5,6 +5,9 @@
>>>   
>>>   #define kvm__arch_get_kern_offset(...)	0x8000
>>>   
>>> +struct kvm;
>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>> +
>>>   #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>   
>>>   #define MAX_PAGE_SIZE	SZ_4K
>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>> index 5e5ee41211ed..9124f6919d0f 100644
>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>> @@ -6,6 +6,7 @@
>>>   struct kvm;
>>>   unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>   int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>   
>>>   #define ARM_MAX_MEMORY(kvm)	({					\
>>>   	u64 max_ram;							\
>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> index 04be43dfa9b2..11250365d8d5 100644
>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> @@ -6,6 +6,8 @@
>>>   			"Run AArch32 guest"),				\
>>>   	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>   			"Create PMUv3 device"),				\
>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>> +			"Enable memory tagging extension"),		\
>>>   	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>   			"Specify random seed for Kernel Address Space "	\
>>>   			"Layout Randomization (KASLR)"),
>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>> index 56a0aedc263d..46548f8ee96e 100644
>>> --- a/arm/aarch64/kvm.c
>>> +++ b/arm/aarch64/kvm.c
>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>   
>>>   	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>   }
>>> +
>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>> +{
>>> +	struct kvm_enable_cap cap = {
>>> +		.cap = KVM_CAP_ARM_MTE,
>>> +	};
>>> +
>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>> +		die("MTE capability is not supported");
>>> +
>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>> +}
>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>> index 5734c46ab9e6..16e8d500a71b 100644
>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>   	bool		virtio_trans_pci;
>>>   	bool		aarch32_guest;
>>>   	bool		has_pmuv3;
>>> +	bool		has_mte;
>>>   	u64		kaslr_seed;
>>>   	enum irqchip_type irqchip;
>>>   	u64		fw_addr;
>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>> index 80d233f13d0b..f2db93953778 100644
>>> --- a/arm/kvm.c
>>> +++ b/arm/kvm.c
>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>   	/* Create the virtual GIC. */
>>>   	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>   		die("Failed to create virtual GIC");
>>> +
>>> +	if (kvm->cfg.arch.has_mte)
>>> +		kvm__arch_enable_mte(kvm);
>>>   }
>>
>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>> PAC and SVE?
> 
> I thought about that, the reason I chose to enable it based a kvmtool
> command line option, instead of always being enabled if available, is
> because of the overhead of sanitising the MTE tags on each stage 2 data
> abort. Steven, am I overreacting and that overhead is negligible?
> 
> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> until the guest starts to use those features.
> 
> Do you have a specific reason for wanting MTE to always be enabled if
> available? I'm happy to be convinced to make MTE enabled by default, I
> don't have preference either way.

Well, automatically enabling if available would align with what we do 
for other features in kvmtool and Linux itself - we tend to default y 
for new features, even MTE, thus improving chances to get reports back 
early if something (even performance) goes wrong. Just my 2p.

Cheers
Vladimir

> 
> Thanks,
> Alex

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> Hi,
> 
> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>> Hi Alexandru,
>>
>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>
>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>> ---
>>>   arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>   arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>   arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>   arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>   arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>   arm/kvm.c                                 |  3 +++
>>>   6 files changed, 23 insertions(+)
>>>
>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>> index bee2fc255a82..5616b27e257e 100644
>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>> @@ -5,6 +5,9 @@
>>>   
>>>   #define kvm__arch_get_kern_offset(...)	0x8000
>>>   
>>> +struct kvm;
>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>> +
>>>   #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>   
>>>   #define MAX_PAGE_SIZE	SZ_4K
>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>> index 5e5ee41211ed..9124f6919d0f 100644
>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>> @@ -6,6 +6,7 @@
>>>   struct kvm;
>>>   unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>   int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>   
>>>   #define ARM_MAX_MEMORY(kvm)	({					\
>>>   	u64 max_ram;							\
>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> index 04be43dfa9b2..11250365d8d5 100644
>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>> @@ -6,6 +6,8 @@
>>>   			"Run AArch32 guest"),				\
>>>   	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>   			"Create PMUv3 device"),				\
>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>> +			"Enable memory tagging extension"),		\
>>>   	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>   			"Specify random seed for Kernel Address Space "	\
>>>   			"Layout Randomization (KASLR)"),
>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>> index 56a0aedc263d..46548f8ee96e 100644
>>> --- a/arm/aarch64/kvm.c
>>> +++ b/arm/aarch64/kvm.c
>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>   
>>>   	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>   }
>>> +
>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>> +{
>>> +	struct kvm_enable_cap cap = {
>>> +		.cap = KVM_CAP_ARM_MTE,
>>> +	};
>>> +
>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>> +		die("MTE capability is not supported");
>>> +
>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>> +}
>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>> index 5734c46ab9e6..16e8d500a71b 100644
>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>   	bool		virtio_trans_pci;
>>>   	bool		aarch32_guest;
>>>   	bool		has_pmuv3;
>>> +	bool		has_mte;
>>>   	u64		kaslr_seed;
>>>   	enum irqchip_type irqchip;
>>>   	u64		fw_addr;
>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>> index 80d233f13d0b..f2db93953778 100644
>>> --- a/arm/kvm.c
>>> +++ b/arm/kvm.c
>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>   	/* Create the virtual GIC. */
>>>   	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>   		die("Failed to create virtual GIC");
>>> +
>>> +	if (kvm->cfg.arch.has_mte)
>>> +		kvm__arch_enable_mte(kvm);
>>>   }
>>
>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>> PAC and SVE?
> 
> I thought about that, the reason I chose to enable it based a kvmtool
> command line option, instead of always being enabled if available, is
> because of the overhead of sanitising the MTE tags on each stage 2 data
> abort. Steven, am I overreacting and that overhead is negligible?
> 
> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> until the guest starts to use those features.
> 
> Do you have a specific reason for wanting MTE to always be enabled if
> available? I'm happy to be convinced to make MTE enabled by default, I
> don't have preference either way.

Well, automatically enabling if available would align with what we do 
for other features in kvmtool and Linux itself - we tend to default y 
for new features, even MTE, thus improving chances to get reports back 
early if something (even performance) goes wrong. Just my 2p.

Cheers
Vladimir

> 
> Thanks,
> Alex


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> > > Hi Alexandru,
> > > 
> > > On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> > > > MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> > > > Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> > > > 
> > > > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > > > ---
> > > >   arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> > > >   arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> > > >   arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> > > >   arm/aarch64/kvm.c                         | 13 +++++++++++++
> > > >   arm/include/arm-common/kvm-config-arch.h  |  1 +
> > > >   arm/kvm.c                                 |  3 +++
> > > >   6 files changed, 23 insertions(+)
> > > > 
> > > > diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> > > > index bee2fc255a82..5616b27e257e 100644
> > > > --- a/arm/aarch32/include/kvm/kvm-arch.h
> > > > +++ b/arm/aarch32/include/kvm/kvm-arch.h
> > > > @@ -5,6 +5,9 @@
> > > >   #define kvm__arch_get_kern_offset(...)	0x8000
> > > > +struct kvm;
> > > > +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> > > > +
> > > >   #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
> > > >   #define MAX_PAGE_SIZE	SZ_4K
> > > > diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> > > > index 5e5ee41211ed..9124f6919d0f 100644
> > > > --- a/arm/aarch64/include/kvm/kvm-arch.h
> > > > +++ b/arm/aarch64/include/kvm/kvm-arch.h
> > > > @@ -6,6 +6,7 @@
> > > >   struct kvm;
> > > >   unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
> > > >   int kvm__arch_get_ipa_limit(struct kvm *kvm);
> > > > +void kvm__arch_enable_mte(struct kvm *kvm);
> > > >   #define ARM_MAX_MEMORY(kvm)	({					\
> > > >   	u64 max_ram;							\
> > > > diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > index 04be43dfa9b2..11250365d8d5 100644
> > > > --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > @@ -6,6 +6,8 @@
> > > >   			"Run AArch32 guest"),				\
> > > >   	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
> > > >   			"Create PMUv3 device"),				\
> > > > +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> > > > +			"Enable memory tagging extension"),		\
> > > >   	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
> > > >   			"Specify random seed for Kernel Address Space "	\
> > > >   			"Layout Randomization (KASLR)"),
> > > > diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> > > > index 56a0aedc263d..46548f8ee96e 100644
> > > > --- a/arm/aarch64/kvm.c
> > > > +++ b/arm/aarch64/kvm.c
> > > > @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> > > >   	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> > > >   }
> > > > +
> > > > +void kvm__arch_enable_mte(struct kvm *kvm)
> > > > +{
> > > > +	struct kvm_enable_cap cap = {
> > > > +		.cap = KVM_CAP_ARM_MTE,
> > > > +	};
> > > > +
> > > > +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> > > > +		die("MTE capability is not supported");
> > > > +
> > > > +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> > > > +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> > > > +}
> > > > diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> > > > index 5734c46ab9e6..16e8d500a71b 100644
> > > > --- a/arm/include/arm-common/kvm-config-arch.h
> > > > +++ b/arm/include/arm-common/kvm-config-arch.h
> > > > @@ -9,6 +9,7 @@ struct kvm_config_arch {
> > > >   	bool		virtio_trans_pci;
> > > >   	bool		aarch32_guest;
> > > >   	bool		has_pmuv3;
> > > > +	bool		has_mte;
> > > >   	u64		kaslr_seed;
> > > >   	enum irqchip_type irqchip;
> > > >   	u64		fw_addr;
> > > > diff --git a/arm/kvm.c b/arm/kvm.c
> > > > index 80d233f13d0b..f2db93953778 100644
> > > > --- a/arm/kvm.c
> > > > +++ b/arm/kvm.c
> > > > @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
> > > >   	/* Create the virtual GIC. */
> > > >   	if (gic__create(kvm, kvm->cfg.arch.irqchip))
> > > >   		die("Failed to create virtual GIC");
> > > > +
> > > > +	if (kvm->cfg.arch.has_mte)
> > > > +		kvm__arch_enable_mte(kvm);
> > > >   }
> > > 
> > > Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> > > PAC and SVE?
> > 
> > I thought about that, the reason I chose to enable it based a kvmtool
> > command line option, instead of always being enabled if available, is
> > because of the overhead of sanitising the MTE tags on each stage 2 data
> > abort. Steven, am I overreacting and that overhead is negligible?
> > 
> > Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> > until the guest starts to use those features.
> > 
> > Do you have a specific reason for wanting MTE to always be enabled if
> > available? I'm happy to be convinced to make MTE enabled by default, I
> > don't have preference either way.
> 
> Well, automatically enabling if available would align with what we do for
> other features in kvmtool and Linux itself - we tend to default y for new
> features, even MTE, thus improving chances to get reports back early if
> something (even performance) goes wrong. Just my 2p.

According to Steven, for each 4k page the kernel uses an 128 byte buffer to
store the tags, and then some extra memory is used to keep track of the
buffers. Let's take the case of a VM with 1GB of memory, and be
conservative and only account for the tag buffer. In this case, the tag
buffers alone will be 32MB.

For a VM with 1GB of memory created with kvmtool built from current master
(commit faae833a746f), pmap shows a total memory usage of 1268388K.
Subtracting the memory of the VM, we are left with 214MB of memory consumed
by kvmtool. Having MTE enabled would increase the memory overhead of
kvmtool by 32/214*100 = 15%.

Of course, this memory overhead scales with the amount of memory the VM
has. The buffer size that KVM uses might change in the future, but since we
cannot predict the future (might become larger or smaller), I'm working
with what is implement today.

The kernel documentation for MTE suggests that in order to take advantage
of it, software must be modified and recompiled. That means that users that
don't want to use MTE won't get to exercise MTE because they won't be using
MTE enabled software, but they will pay the overhead regardless. This of
course assumes that going forward software won't be using MTE by default.

kvmtool is supposed to be simple, fast and less resource intensive than
other hypervisors, that's why I think having MTE disabled by default is the
best way to implement the capability.

Thanks,
Alex

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> > > Hi Alexandru,
> > > 
> > > On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> > > > MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
> > > > Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> > > > 
> > > > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > > > ---
> > > >   arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> > > >   arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> > > >   arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> > > >   arm/aarch64/kvm.c                         | 13 +++++++++++++
> > > >   arm/include/arm-common/kvm-config-arch.h  |  1 +
> > > >   arm/kvm.c                                 |  3 +++
> > > >   6 files changed, 23 insertions(+)
> > > > 
> > > > diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
> > > > index bee2fc255a82..5616b27e257e 100644
> > > > --- a/arm/aarch32/include/kvm/kvm-arch.h
> > > > +++ b/arm/aarch32/include/kvm/kvm-arch.h
> > > > @@ -5,6 +5,9 @@
> > > >   #define kvm__arch_get_kern_offset(...)	0x8000
> > > > +struct kvm;
> > > > +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> > > > +
> > > >   #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
> > > >   #define MAX_PAGE_SIZE	SZ_4K
> > > > diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
> > > > index 5e5ee41211ed..9124f6919d0f 100644
> > > > --- a/arm/aarch64/include/kvm/kvm-arch.h
> > > > +++ b/arm/aarch64/include/kvm/kvm-arch.h
> > > > @@ -6,6 +6,7 @@
> > > >   struct kvm;
> > > >   unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
> > > >   int kvm__arch_get_ipa_limit(struct kvm *kvm);
> > > > +void kvm__arch_enable_mte(struct kvm *kvm);
> > > >   #define ARM_MAX_MEMORY(kvm)	({					\
> > > >   	u64 max_ram;							\
> > > > diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > index 04be43dfa9b2..11250365d8d5 100644
> > > > --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> > > > @@ -6,6 +6,8 @@
> > > >   			"Run AArch32 guest"),				\
> > > >   	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
> > > >   			"Create PMUv3 device"),				\
> > > > +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
> > > > +			"Enable memory tagging extension"),		\
> > > >   	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
> > > >   			"Specify random seed for Kernel Address Space "	\
> > > >   			"Layout Randomization (KASLR)"),
> > > > diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> > > > index 56a0aedc263d..46548f8ee96e 100644
> > > > --- a/arm/aarch64/kvm.c
> > > > +++ b/arm/aarch64/kvm.c
> > > > @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> > > >   	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> > > >   }
> > > > +
> > > > +void kvm__arch_enable_mte(struct kvm *kvm)
> > > > +{
> > > > +	struct kvm_enable_cap cap = {
> > > > +		.cap = KVM_CAP_ARM_MTE,
> > > > +	};
> > > > +
> > > > +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> > > > +		die("MTE capability is not supported");
> > > > +
> > > > +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> > > > +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> > > > +}
> > > > diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
> > > > index 5734c46ab9e6..16e8d500a71b 100644
> > > > --- a/arm/include/arm-common/kvm-config-arch.h
> > > > +++ b/arm/include/arm-common/kvm-config-arch.h
> > > > @@ -9,6 +9,7 @@ struct kvm_config_arch {
> > > >   	bool		virtio_trans_pci;
> > > >   	bool		aarch32_guest;
> > > >   	bool		has_pmuv3;
> > > > +	bool		has_mte;
> > > >   	u64		kaslr_seed;
> > > >   	enum irqchip_type irqchip;
> > > >   	u64		fw_addr;
> > > > diff --git a/arm/kvm.c b/arm/kvm.c
> > > > index 80d233f13d0b..f2db93953778 100644
> > > > --- a/arm/kvm.c
> > > > +++ b/arm/kvm.c
> > > > @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
> > > >   	/* Create the virtual GIC. */
> > > >   	if (gic__create(kvm, kvm->cfg.arch.irqchip))
> > > >   		die("Failed to create virtual GIC");
> > > > +
> > > > +	if (kvm->cfg.arch.has_mte)
> > > > +		kvm__arch_enable_mte(kvm);
> > > >   }
> > > 
> > > Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> > > PAC and SVE?
> > 
> > I thought about that, the reason I chose to enable it based a kvmtool
> > command line option, instead of always being enabled if available, is
> > because of the overhead of sanitising the MTE tags on each stage 2 data
> > abort. Steven, am I overreacting and that overhead is negligible?
> > 
> > Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> > until the guest starts to use those features.
> > 
> > Do you have a specific reason for wanting MTE to always be enabled if
> > available? I'm happy to be convinced to make MTE enabled by default, I
> > don't have preference either way.
> 
> Well, automatically enabling if available would align with what we do for
> other features in kvmtool and Linux itself - we tend to default y for new
> features, even MTE, thus improving chances to get reports back early if
> something (even performance) goes wrong. Just my 2p.

According to Steven, for each 4k page the kernel uses an 128 byte buffer to
store the tags, and then some extra memory is used to keep track of the
buffers. Let's take the case of a VM with 1GB of memory, and be
conservative and only account for the tag buffer. In this case, the tag
buffers alone will be 32MB.

For a VM with 1GB of memory created with kvmtool built from current master
(commit faae833a746f), pmap shows a total memory usage of 1268388K.
Subtracting the memory of the VM, we are left with 214MB of memory consumed
by kvmtool. Having MTE enabled would increase the memory overhead of
kvmtool by 32/214*100 = 15%.

Of course, this memory overhead scales with the amount of memory the VM
has. The buffer size that KVM uses might change in the future, but since we
cannot predict the future (might become larger or smaller), I'm working
with what is implement today.

The kernel documentation for MTE suggests that in order to take advantage
of it, software must be modified and recompiled. That means that users that
don't want to use MTE won't get to exercise MTE because they won't be using
MTE enabled software, but they will pay the overhead regardless. This of
course assumes that going forward software won't be using MTE by default.

kvmtool is supposed to be simple, fast and less resource intensive than
other hypervisors, that's why I think having MTE disabled by default is the
best way to implement the capability.

Thanks,
Alex

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Catalin Marinas]

On Wed, Mar 23, 2022 at 12:03:33PM +0000, Alexandru Elisei wrote:
> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> > On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> > > On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> > > > Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> > > > PAC and SVE?
> > > 
> > > I thought about that, the reason I chose to enable it based a kvmtool
> > > command line option, instead of always being enabled if available, is
> > > because of the overhead of sanitising the MTE tags on each stage 2 data
> > > abort. Steven, am I overreacting and that overhead is negligible?
> > > 
> > > Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> > > until the guest starts to use those features.
> > > 
> > > Do you have a specific reason for wanting MTE to always be enabled if
> > > available? I'm happy to be convinced to make MTE enabled by default, I
> > > don't have preference either way.
> > 
> > Well, automatically enabling if available would align with what we do for
> > other features in kvmtool and Linux itself - we tend to default y for new
> > features, even MTE, thus improving chances to get reports back early if
> > something (even performance) goes wrong. Just my 2p.
> 
> According to Steven, for each 4k page the kernel uses an 128 byte buffer to
> store the tags, and then some extra memory is used to keep track of the
> buffers. Let's take the case of a VM with 1GB of memory, and be
> conservative and only account for the tag buffer. In this case, the tag
> buffers alone will be 32MB.

The 128 byte buffer is only allocated *if* the page is swapped out. So
if the host swaps out the entire 1GB guest memory, it will incur the
32MB cost. But a fully swapped out VM is pretty useless, so this doesn't
happen very often.

We do have the cost of zeroing the tags when the page is mapped into
guests. I don't remember the KVM implementation but maybe we can
optimise this to zero the tags at the same time with zeroing the data
as we do for anonymous pages in the host (unless it does this already).

We could use the fine-grained traps to detect when MAIR_EL1 was
configured by the guest for Tagged memory but, at least with Linux, we
do this at boot irrespective of whether any application will use MTE or
not. Future architecture versions may address this problem.

> The kernel documentation for MTE suggests that in order to take advantage
> of it, software must be modified and recompiled. That means that users that
> don't want to use MTE won't get to exercise MTE because they won't be using
> MTE enabled software, but they will pay the overhead regardless. This of
> course assumes that going forward software won't be using MTE by default.

Not all software needs to be recompiled. It's sufficient most of the
time to replace the glibc with an MTE-aware one.

I have a slight preference for MTE default in kvmtool, maybe with an
option to disable it if one doesn't care about the feature or we find
the overhead to be significant (I don't think it would be).

-- 
Catalin

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Catalin Marinas]

On Wed, Mar 23, 2022 at 12:03:33PM +0000, Alexandru Elisei wrote:
> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> > On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> > > On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> > > > Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
> > > > PAC and SVE?
> > > 
> > > I thought about that, the reason I chose to enable it based a kvmtool
> > > command line option, instead of always being enabled if available, is
> > > because of the overhead of sanitising the MTE tags on each stage 2 data
> > > abort. Steven, am I overreacting and that overhead is negligible?
> > > 
> > > Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> > > until the guest starts to use those features.
> > > 
> > > Do you have a specific reason for wanting MTE to always be enabled if
> > > available? I'm happy to be convinced to make MTE enabled by default, I
> > > don't have preference either way.
> > 
> > Well, automatically enabling if available would align with what we do for
> > other features in kvmtool and Linux itself - we tend to default y for new
> > features, even MTE, thus improving chances to get reports back early if
> > something (even performance) goes wrong. Just my 2p.
> 
> According to Steven, for each 4k page the kernel uses an 128 byte buffer to
> store the tags, and then some extra memory is used to keep track of the
> buffers. Let's take the case of a VM with 1GB of memory, and be
> conservative and only account for the tag buffer. In this case, the tag
> buffers alone will be 32MB.

The 128 byte buffer is only allocated *if* the page is swapped out. So
if the host swaps out the entire 1GB guest memory, it will incur the
32MB cost. But a fully swapped out VM is pretty useless, so this doesn't
happen very often.

We do have the cost of zeroing the tags when the page is mapped into
guests. I don't remember the KVM implementation but maybe we can
optimise this to zero the tags at the same time with zeroing the data
as we do for anonymous pages in the host (unless it does this already).

We could use the fine-grained traps to detect when MAIR_EL1 was
configured by the guest for Tagged memory but, at least with Linux, we
do this at boot irrespective of whether any application will use MTE or
not. Future architecture versions may address this problem.

> The kernel documentation for MTE suggests that in order to take advantage
> of it, software must be modified and recompiled. That means that users that
> don't want to use MTE won't get to exercise MTE because they won't be using
> MTE enabled software, but they will pay the overhead regardless. This of
> course assumes that going forward software won't be using MTE by default.

Not all software needs to be recompiled. It's sufficient most of the
time to replace the glibc with an MTE-aware one.

I have a slight preference for MTE default in kvmtool, maybe with an
option to disable it if one doesn't care about the feature or we find
the overhead to be significant (I don't think it would be).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

Hi,

On 3/23/22 12:03 PM, Alexandru Elisei wrote:
> Hi,
> 
> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>>>> Hi Alexandru,
>>>>
>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>>>
>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>>>> ---
>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>>>    arm/kvm.c                                 |  3 +++
>>>>>    6 files changed, 23 insertions(+)
>>>>>
>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>>>> index bee2fc255a82..5616b27e257e 100644
>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>>>> @@ -5,6 +5,9 @@
>>>>>    #define kvm__arch_get_kern_offset(...)	0x8000
>>>>> +struct kvm;
>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>>>> +
>>>>>    #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>>>    #define MAX_PAGE_SIZE	SZ_4K
>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>>>> index 5e5ee41211ed..9124f6919d0f 100644
>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>>>> @@ -6,6 +6,7 @@
>>>>>    struct kvm;
>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>>>    #define ARM_MAX_MEMORY(kvm)	({					\
>>>>>    	u64 max_ram;							\
>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> index 04be43dfa9b2..11250365d8d5 100644
>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> @@ -6,6 +6,8 @@
>>>>>    			"Run AArch32 guest"),				\
>>>>>    	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>>>    			"Create PMUv3 device"),				\
>>>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>>>> +			"Enable memory tagging extension"),		\
>>>>>    	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>>>    			"Specify random seed for Kernel Address Space "	\
>>>>>    			"Layout Randomization (KASLR)"),
>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>>>> index 56a0aedc263d..46548f8ee96e 100644
>>>>> --- a/arm/aarch64/kvm.c
>>>>> +++ b/arm/aarch64/kvm.c
>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>>>    	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>>>    }
>>>>> +
>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>>>> +{
>>>>> +	struct kvm_enable_cap cap = {
>>>>> +		.cap = KVM_CAP_ARM_MTE,
>>>>> +	};
>>>>> +
>>>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>>>> +		die("MTE capability is not supported");
>>>>> +
>>>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>>>> +}
>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>>>> index 5734c46ab9e6..16e8d500a71b 100644
>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>>>    	bool		virtio_trans_pci;
>>>>>    	bool		aarch32_guest;
>>>>>    	bool		has_pmuv3;
>>>>> +	bool		has_mte;
>>>>>    	u64		kaslr_seed;
>>>>>    	enum irqchip_type irqchip;
>>>>>    	u64		fw_addr;
>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>>>> index 80d233f13d0b..f2db93953778 100644
>>>>> --- a/arm/kvm.c
>>>>> +++ b/arm/kvm.c
>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>>>    	/* Create the virtual GIC. */
>>>>>    	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>>>    		die("Failed to create virtual GIC");
>>>>> +
>>>>> +	if (kvm->cfg.arch.has_mte)
>>>>> +		kvm__arch_enable_mte(kvm);
>>>>>    }
>>>>
>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>>>> PAC and SVE?
>>>
>>> I thought about that, the reason I chose to enable it based a kvmtool
>>> command line option, instead of always being enabled if available, is
>>> because of the overhead of sanitising the MTE tags on each stage 2 data
>>> abort. Steven, am I overreacting and that overhead is negligible?
>>>
>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
>>> until the guest starts to use those features.
>>>
>>> Do you have a specific reason for wanting MTE to always be enabled if
>>> available? I'm happy to be convinced to make MTE enabled by default, I
>>> don't have preference either way.
>>
>> Well, automatically enabling if available would align with what we do for
>> other features in kvmtool and Linux itself - we tend to default y for new
>> features, even MTE, thus improving chances to get reports back early if
>> something (even performance) goes wrong. Just my 2p.
> 
> According to Steven, for each 4k page the kernel uses an 128 byte buffer to
> store the tags, and then some extra memory is used to keep track of the
> buffers. Let's take the case of a VM with 1GB of memory, and be
> conservative and only account for the tag buffer. In this case, the tag
> buffers alone will be 32MB.

Right, IIUC, that memory is allocated on demand when we about to swap the page
out or perform hibernation, so there is no reservation done upfront or I'm
missing something?

> 
> For a VM with 1GB of memory created with kvmtool built from current master
> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
> Subtracting the memory of the VM, we are left with 214MB of memory consumed
> by kvmtool. Having MTE enabled would increase the memory overhead of
> kvmtool by 32/214*100 = 15%.
> 

I admit, I might be missing something, but given that extra tag storage
allocated for swap/hibernation overhead can be applied to any process which
uses MTE, no?

> Of course, this memory overhead scales with the amount of memory the VM
> has. The buffer size that KVM uses might change in the future, but since we
> cannot predict the future (might become larger or smaller), I'm working
> with what is implement today.
>

Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory overhead
won't magically disappear, so should we start thinking how to reduce it?
I noticed that code saves tags one to one, so for guest which doesn't
actively use MTE whole page would be tagged with zero, cannot that case be
optimized? or maybe be go further and compress tags?
  
> The kernel documentation for MTE suggests that in order to take advantage
> of it, software must be modified and recompiled. That means that users that
> don't want to use MTE won't get to exercise MTE because they won't be using
> MTE enabled software, but they will pay the overhead regardless. This of
> course assumes that going forward software won't be using MTE by default.
> 
> kvmtool is supposed to be simple, fast and less resource intensive than
> other hypervisors, that's why I think having MTE disabled by default is the
> best way to implement the capability.

I see kvmtool as bleeding edge hacking tool, so closer it to the edge is better :)

Cheers
Vladimir

> 
> Thanks,
> Alex

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Vladimir Murzin]

Hi,

On 3/23/22 12:03 PM, Alexandru Elisei wrote:
> Hi,
> 
> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>>>> Hi Alexandru,
>>>>
>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64:
>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>>>
>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>>>> ---
>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>>>    arm/kvm.c                                 |  3 +++
>>>>>    6 files changed, 23 insertions(+)
>>>>>
>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
>>>>> index bee2fc255a82..5616b27e257e 100644
>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>>>> @@ -5,6 +5,9 @@
>>>>>    #define kvm__arch_get_kern_offset(...)	0x8000
>>>>> +struct kvm;
>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>>>> +
>>>>>    #define ARM_MAX_MEMORY(...)	ARM_LOMAP_MAX_MEMORY
>>>>>    #define MAX_PAGE_SIZE	SZ_4K
>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
>>>>> index 5e5ee41211ed..9124f6919d0f 100644
>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>>>> @@ -6,6 +6,7 @@
>>>>>    struct kvm;
>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd);
>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>>>    #define ARM_MAX_MEMORY(kvm)	({					\
>>>>>    	u64 max_ram;							\
>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> index 04be43dfa9b2..11250365d8d5 100644
>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>> @@ -6,6 +6,8 @@
>>>>>    			"Run AArch32 guest"),				\
>>>>>    	OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,			\
>>>>>    			"Create PMUv3 device"),				\
>>>>> +	OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,			\
>>>>> +			"Enable memory tagging extension"),		\
>>>>>    	OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,			\
>>>>>    			"Specify random seed for Kernel Address Space "	\
>>>>>    			"Layout Randomization (KASLR)"),
>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>>>> index 56a0aedc263d..46548f8ee96e 100644
>>>>> --- a/arm/aarch64/kvm.c
>>>>> +++ b/arm/aarch64/kvm.c
>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>>>    	return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>>>    }
>>>>> +
>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>>>> +{
>>>>> +	struct kvm_enable_cap cap = {
>>>>> +		.cap = KVM_CAP_ARM_MTE,
>>>>> +	};
>>>>> +
>>>>> +	if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>>>> +		die("MTE capability is not supported");
>>>>> +
>>>>> +	if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>>>> +		die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>>>> +}
>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
>>>>> index 5734c46ab9e6..16e8d500a71b 100644
>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>>>    	bool		virtio_trans_pci;
>>>>>    	bool		aarch32_guest;
>>>>>    	bool		has_pmuv3;
>>>>> +	bool		has_mte;
>>>>>    	u64		kaslr_seed;
>>>>>    	enum irqchip_type irqchip;
>>>>>    	u64		fw_addr;
>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>>>> index 80d233f13d0b..f2db93953778 100644
>>>>> --- a/arm/kvm.c
>>>>> +++ b/arm/kvm.c
>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char *hugetlbfs_path, u64 ram_size)
>>>>>    	/* Create the virtual GIC. */
>>>>>    	if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>>>    		die("Failed to create virtual GIC");
>>>>> +
>>>>> +	if (kvm->cfg.arch.has_mte)
>>>>> +		kvm__arch_enable_mte(kvm);
>>>>>    }
>>>>
>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for
>>>> PAC and SVE?
>>>
>>> I thought about that, the reason I chose to enable it based a kvmtool
>>> command line option, instead of always being enabled if available, is
>>> because of the overhead of sanitising the MTE tags on each stage 2 data
>>> abort. Steven, am I overreacting and that overhead is negligible?
>>>
>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
>>> until the guest starts to use those features.
>>>
>>> Do you have a specific reason for wanting MTE to always be enabled if
>>> available? I'm happy to be convinced to make MTE enabled by default, I
>>> don't have preference either way.
>>
>> Well, automatically enabling if available would align with what we do for
>> other features in kvmtool and Linux itself - we tend to default y for new
>> features, even MTE, thus improving chances to get reports back early if
>> something (even performance) goes wrong. Just my 2p.
> 
> According to Steven, for each 4k page the kernel uses an 128 byte buffer to
> store the tags, and then some extra memory is used to keep track of the
> buffers. Let's take the case of a VM with 1GB of memory, and be
> conservative and only account for the tag buffer. In this case, the tag
> buffers alone will be 32MB.

Right, IIUC, that memory is allocated on demand when we about to swap the page
out or perform hibernation, so there is no reservation done upfront or I'm
missing something?

> 
> For a VM with 1GB of memory created with kvmtool built from current master
> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
> Subtracting the memory of the VM, we are left with 214MB of memory consumed
> by kvmtool. Having MTE enabled would increase the memory overhead of
> kvmtool by 32/214*100 = 15%.
> 

I admit, I might be missing something, but given that extra tag storage
allocated for swap/hibernation overhead can be applied to any process which
uses MTE, no?

> Of course, this memory overhead scales with the amount of memory the VM
> has. The buffer size that KVM uses might change in the future, but since we
> cannot predict the future (might become larger or smaller), I'm working
> with what is implement today.
>

Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory overhead
won't magically disappear, so should we start thinking how to reduce it?
I noticed that code saves tags one to one, so for guest which doesn't
actively use MTE whole page would be tagged with zero, cannot that case be
optimized? or maybe be go further and compress tags?
  
> The kernel documentation for MTE suggests that in order to take advantage
> of it, software must be modified and recompiled. That means that users that
> don't want to use MTE won't get to exercise MTE because they won't be using
> MTE enabled software, but they will pay the overhead regardless. This of
> course assumes that going forward software won't be using MTE by default.
> 
> kvmtool is supposed to be simple, fast and less resource intensive than
> other hypervisors, that's why I think having MTE disabled by default is the
> best way to implement the capability.

I see kvmtool as bleeding edge hacking tool, so closer it to the edge is better :)

Cheers
Vladimir

> 
> Thanks,
> Alex


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Steven Price]

On 23/03/2022 13:57, Vladimir Murzin wrote:
> Hi,
> 
> On 3/23/22 12:03 PM, Alexandru Elisei wrote:
>> Hi,
>>
>> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
>>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
>>>> Hi,
>>>>
>>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>>>>> Hi Alexandru,
>>>>>
>>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM:
>>>>>> arm64:
>>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>>>>
>>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>>>>> ---
>>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>>>>    arm/kvm.c                                 |  3 +++
>>>>>>    6 files changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> b/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> index bee2fc255a82..5616b27e257e 100644
>>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> @@ -5,6 +5,9 @@
>>>>>>    #define kvm__arch_get_kern_offset(...)    0x8000
>>>>>> +struct kvm;
>>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>>>>> +
>>>>>>    #define ARM_MAX_MEMORY(...)    ARM_LOMAP_MAX_MEMORY
>>>>>>    #define MAX_PAGE_SIZE    SZ_4K
>>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> b/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> index 5e5ee41211ed..9124f6919d0f 100644
>>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> @@ -6,6 +6,7 @@
>>>>>>    struct kvm;
>>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm,
>>>>>> int fd);
>>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>>>>    #define ARM_MAX_MEMORY(kvm)    ({                    \
>>>>>>        u64 max_ram;                            \
>>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> index 04be43dfa9b2..11250365d8d5 100644
>>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> @@ -6,6 +6,8 @@
>>>>>>                "Run AArch32 guest"),                \
>>>>>>        OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,            \
>>>>>>                "Create PMUv3 device"),                \
>>>>>> +    OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,            \
>>>>>> +            "Enable memory tagging extension"),        \
>>>>>>        OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,            \
>>>>>>                "Specify random seed for Kernel Address Space "    \
>>>>>>                "Layout Randomization (KASLR)"),
>>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>>>>> index 56a0aedc263d..46548f8ee96e 100644
>>>>>> --- a/arm/aarch64/kvm.c
>>>>>> +++ b/arm/aarch64/kvm.c
>>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>>>>        return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>>>>    }
>>>>>> +
>>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>>>>> +{
>>>>>> +    struct kvm_enable_cap cap = {
>>>>>> +        .cap = KVM_CAP_ARM_MTE,
>>>>>> +    };
>>>>>> +
>>>>>> +    if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>>>>> +        die("MTE capability is not supported");
>>>>>> +
>>>>>> +    if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>>>>> +        die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>>>>> +}
>>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h
>>>>>> b/arm/include/arm-common/kvm-config-arch.h
>>>>>> index 5734c46ab9e6..16e8d500a71b 100644
>>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>>>>        bool        virtio_trans_pci;
>>>>>>        bool        aarch32_guest;
>>>>>>        bool        has_pmuv3;
>>>>>> +    bool        has_mte;
>>>>>>        u64        kaslr_seed;
>>>>>>        enum irqchip_type irqchip;
>>>>>>        u64        fw_addr;
>>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>>>>> index 80d233f13d0b..f2db93953778 100644
>>>>>> --- a/arm/kvm.c
>>>>>> +++ b/arm/kvm.c
>>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char
>>>>>> *hugetlbfs_path, u64 ram_size)
>>>>>>        /* Create the virtual GIC. */
>>>>>>        if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>>>>            die("Failed to create virtual GIC");
>>>>>> +
>>>>>> +    if (kvm->cfg.arch.has_mte)
>>>>>> +        kvm__arch_enable_mte(kvm);
>>>>>>    }
>>>>>
>>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported
>>>>> like we do for
>>>>> PAC and SVE?
>>>>
>>>> I thought about that, the reason I chose to enable it based a kvmtool
>>>> command line option, instead of always being enabled if available, is
>>>> because of the overhead of sanitising the MTE tags on each stage 2 data
>>>> abort. Steven, am I overreacting and that overhead is negligible?
>>>>
>>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
>>>> until the guest starts to use those features.
>>>>
>>>> Do you have a specific reason for wanting MTE to always be enabled if
>>>> available? I'm happy to be convinced to make MTE enabled by default, I
>>>> don't have preference either way.
>>>
>>> Well, automatically enabling if available would align with what we do
>>> for
>>> other features in kvmtool and Linux itself - we tend to default y for
>>> new
>>> features, even MTE, thus improving chances to get reports back early if
>>> something (even performance) goes wrong. Just my 2p.
>>
>> According to Steven, for each 4k page the kernel uses an 128 byte
>> buffer to
>> store the tags, and then some extra memory is used to keep track of the
>> buffers. Let's take the case of a VM with 1GB of memory, and be
>> conservative and only account for the tag buffer. In this case, the tag
>> buffers alone will be 32MB.
> 
> Right, IIUC, that memory is allocated on demand when we about to swap
> the page
> out or perform hibernation, so there is no reservation done upfront or I'm
> missing something?

That's correct, sorry if I didn't make that clear earlier. The host
memory is only allocated when the MTE-enabled guest's pages are swapped
out. So if they are never swapped out there's no memory overhead.

>>
>> For a VM with 1GB of memory created with kvmtool built from current
>> master
>> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
>> Subtracting the memory of the VM, we are left with 214MB of memory
>> consumed
>> by kvmtool. Having MTE enabled would increase the memory overhead of
>> kvmtool by 32/214*100 = 15%.
>>
> 
> I admit, I might be missing something, but given that extra tag storage
> allocated for swap/hibernation overhead can be applied to any process which
> uses MTE, no?

One difference is that the entire VM is considered MTE memory, whereas
in a normal application only those pages mapped with PROT_MTE take the
overhead. So the memory overhead of applications running in the VM is
higher than the same application outside of the VM (assuming the memory
is swapped out by the host).

>> Of course, this memory overhead scales with the amount of memory the VM
>> has. The buffer size that KVM uses might change in the future, but
>> since we
>> cannot predict the future (might become larger or smaller), I'm working
>> with what is implement today.
>>
> 
> Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory
> overhead
> won't magically disappear, so should we start thinking how to reduce it?
> I noticed that code saves tags one to one, so for guest which doesn't
> actively use MTE whole page would be tagged with zero, cannot that case be
> optimized? or maybe be go further and compress tags?

Compressing tags is certainly something that could be considered (an
early revision of the MTE swap did optimise the zero case).

However Linux is lazy with the tags - if an application needs memory but
doesn't use the tags then only the data portion will be zeroed and the
tags will be left with whatever value they had previously (as they are
not accessible by the application). This could mean that a MTE-enabled
guest ends with with remarkably few pages with zeroed tags after it has
been running for a while.

From the host it's not possible to determine whether the tags are useful
or not so they have to be saved regardless.

That said I don't have a strong opinion on the default, as long as
there's an option to disable MTE then having the default with it turned
on is fine by me.

>> The kernel documentation for MTE suggests that in order to take advantage
>> of it, software must be modified and recompiled. That means that users
>> that
>> don't want to use MTE won't get to exercise MTE because they won't be
>> using
>> MTE enabled software, but they will pay the overhead regardless. This of
>> course assumes that going forward software won't be using MTE by default.
>>
>> kvmtool is supposed to be simple, fast and less resource intensive than
>> other hypervisors, that's why I think having MTE disabled by default
>> is the
>> best way to implement the capability.
> 
> I see kvmtool as bleeding edge hacking tool, so closer it to the edge is
> better :)

I have to admit I like the "just works" approach that the defaults give
you (e.g. p9 filesystem from host, no need to configure root filesystems
etc), so there's definitely something to be said for MTE "just working"
in kvmtool too.

Steve

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Steven Price]

On 23/03/2022 13:57, Vladimir Murzin wrote:
> Hi,
> 
> On 3/23/22 12:03 PM, Alexandru Elisei wrote:
>> Hi,
>>
>> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
>>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
>>>> Hi,
>>>>
>>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
>>>>> Hi Alexandru,
>>>>>
>>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
>>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM:
>>>>>> arm64:
>>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
>>>>>>
>>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
>>>>>> ---
>>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
>>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
>>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
>>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
>>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
>>>>>>    arm/kvm.c                                 |  3 +++
>>>>>>    6 files changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> b/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> index bee2fc255a82..5616b27e257e 100644
>>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
>>>>>> @@ -5,6 +5,9 @@
>>>>>>    #define kvm__arch_get_kern_offset(...)    0x8000
>>>>>> +struct kvm;
>>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
>>>>>> +
>>>>>>    #define ARM_MAX_MEMORY(...)    ARM_LOMAP_MAX_MEMORY
>>>>>>    #define MAX_PAGE_SIZE    SZ_4K
>>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> b/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> index 5e5ee41211ed..9124f6919d0f 100644
>>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
>>>>>> @@ -6,6 +6,7 @@
>>>>>>    struct kvm;
>>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm,
>>>>>> int fd);
>>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
>>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
>>>>>>    #define ARM_MAX_MEMORY(kvm)    ({                    \
>>>>>>        u64 max_ram;                            \
>>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> index 04be43dfa9b2..11250365d8d5 100644
>>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
>>>>>> @@ -6,6 +6,8 @@
>>>>>>                "Run AArch32 guest"),                \
>>>>>>        OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,            \
>>>>>>                "Create PMUv3 device"),                \
>>>>>> +    OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,            \
>>>>>> +            "Enable memory tagging extension"),        \
>>>>>>        OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,            \
>>>>>>                "Specify random seed for Kernel Address Space "    \
>>>>>>                "Layout Randomization (KASLR)"),
>>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
>>>>>> index 56a0aedc263d..46548f8ee96e 100644
>>>>>> --- a/arm/aarch64/kvm.c
>>>>>> +++ b/arm/aarch64/kvm.c
>>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
>>>>>>        return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
>>>>>>    }
>>>>>> +
>>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
>>>>>> +{
>>>>>> +    struct kvm_enable_cap cap = {
>>>>>> +        .cap = KVM_CAP_ARM_MTE,
>>>>>> +    };
>>>>>> +
>>>>>> +    if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
>>>>>> +        die("MTE capability is not supported");
>>>>>> +
>>>>>> +    if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
>>>>>> +        die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
>>>>>> +}
>>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h
>>>>>> b/arm/include/arm-common/kvm-config-arch.h
>>>>>> index 5734c46ab9e6..16e8d500a71b 100644
>>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
>>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
>>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
>>>>>>        bool        virtio_trans_pci;
>>>>>>        bool        aarch32_guest;
>>>>>>        bool        has_pmuv3;
>>>>>> +    bool        has_mte;
>>>>>>        u64        kaslr_seed;
>>>>>>        enum irqchip_type irqchip;
>>>>>>        u64        fw_addr;
>>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>>>>> index 80d233f13d0b..f2db93953778 100644
>>>>>> --- a/arm/kvm.c
>>>>>> +++ b/arm/kvm.c
>>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char
>>>>>> *hugetlbfs_path, u64 ram_size)
>>>>>>        /* Create the virtual GIC. */
>>>>>>        if (gic__create(kvm, kvm->cfg.arch.irqchip))
>>>>>>            die("Failed to create virtual GIC");
>>>>>> +
>>>>>> +    if (kvm->cfg.arch.has_mte)
>>>>>> +        kvm__arch_enable_mte(kvm);
>>>>>>    }
>>>>>
>>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported
>>>>> like we do for
>>>>> PAC and SVE?
>>>>
>>>> I thought about that, the reason I chose to enable it based a kvmtool
>>>> command line option, instead of always being enabled if available, is
>>>> because of the overhead of sanitising the MTE tags on each stage 2 data
>>>> abort. Steven, am I overreacting and that overhead is negligible?
>>>>
>>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
>>>> until the guest starts to use those features.
>>>>
>>>> Do you have a specific reason for wanting MTE to always be enabled if
>>>> available? I'm happy to be convinced to make MTE enabled by default, I
>>>> don't have preference either way.
>>>
>>> Well, automatically enabling if available would align with what we do
>>> for
>>> other features in kvmtool and Linux itself - we tend to default y for
>>> new
>>> features, even MTE, thus improving chances to get reports back early if
>>> something (even performance) goes wrong. Just my 2p.
>>
>> According to Steven, for each 4k page the kernel uses an 128 byte
>> buffer to
>> store the tags, and then some extra memory is used to keep track of the
>> buffers. Let's take the case of a VM with 1GB of memory, and be
>> conservative and only account for the tag buffer. In this case, the tag
>> buffers alone will be 32MB.
> 
> Right, IIUC, that memory is allocated on demand when we about to swap
> the page
> out or perform hibernation, so there is no reservation done upfront or I'm
> missing something?

That's correct, sorry if I didn't make that clear earlier. The host
memory is only allocated when the MTE-enabled guest's pages are swapped
out. So if they are never swapped out there's no memory overhead.

>>
>> For a VM with 1GB of memory created with kvmtool built from current
>> master
>> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
>> Subtracting the memory of the VM, we are left with 214MB of memory
>> consumed
>> by kvmtool. Having MTE enabled would increase the memory overhead of
>> kvmtool by 32/214*100 = 15%.
>>
> 
> I admit, I might be missing something, but given that extra tag storage
> allocated for swap/hibernation overhead can be applied to any process which
> uses MTE, no?

One difference is that the entire VM is considered MTE memory, whereas
in a normal application only those pages mapped with PROT_MTE take the
overhead. So the memory overhead of applications running in the VM is
higher than the same application outside of the VM (assuming the memory
is swapped out by the host).

>> Of course, this memory overhead scales with the amount of memory the VM
>> has. The buffer size that KVM uses might change in the future, but
>> since we
>> cannot predict the future (might become larger or smaller), I'm working
>> with what is implement today.
>>
> 
> Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory
> overhead
> won't magically disappear, so should we start thinking how to reduce it?
> I noticed that code saves tags one to one, so for guest which doesn't
> actively use MTE whole page would be tagged with zero, cannot that case be
> optimized? or maybe be go further and compress tags?

Compressing tags is certainly something that could be considered (an
early revision of the MTE swap did optimise the zero case).

However Linux is lazy with the tags - if an application needs memory but
doesn't use the tags then only the data portion will be zeroed and the
tags will be left with whatever value they had previously (as they are
not accessible by the application). This could mean that a MTE-enabled
guest ends with with remarkably few pages with zeroed tags after it has
been running for a while.

From the host it's not possible to determine whether the tags are useful
or not so they have to be saved regardless.

That said I don't have a strong opinion on the default, as long as
there's an option to disable MTE then having the default with it turned
on is fine by me.

>> The kernel documentation for MTE suggests that in order to take advantage
>> of it, software must be modified and recompiled. That means that users
>> that
>> don't want to use MTE won't get to exercise MTE because they won't be
>> using
>> MTE enabled software, but they will pay the overhead regardless. This of
>> course assumes that going forward software won't be using MTE by default.
>>
>> kvmtool is supposed to be simple, fast and less resource intensive than
>> other hypervisors, that's why I think having MTE disabled by default
>> is the
>> best way to implement the capability.
> 
> I see kvmtool as bleeding edge hacking tool, so closer it to the edge is
> better :)

I have to admit I like the "just works" approach that the defaults give
you (e.g. p9 filesystem from host, no need to configure root filesystems
etc), so there's definitely something to be said for MTE "just working"
in kvmtool too.

Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

Catalin, Steven, Vladimir, thank you all for the feedback. I'll make MTE
enabled by default in the next iteration of this series.

Thanks,
Alex

On Wed, Mar 23, 2022 at 02:15:55PM +0000, Steven Price wrote:
> On 23/03/2022 13:57, Vladimir Murzin wrote:
> > Hi,
> > 
> > On 3/23/22 12:03 PM, Alexandru Elisei wrote:
> >> Hi,
> >>
> >> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> >>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> >>>> Hi,
> >>>>
> >>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> >>>>> Hi Alexandru,
> >>>>>
> >>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> >>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM:
> >>>>>> arm64:
> >>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> >>>>>>
> >>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> >>>>>> ---
> >>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> >>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> >>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> >>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
> >>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
> >>>>>>    arm/kvm.c                                 |  3 +++
> >>>>>>    6 files changed, 23 insertions(+)
> >>>>>>
> >>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> b/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> index bee2fc255a82..5616b27e257e 100644
> >>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> @@ -5,6 +5,9 @@
> >>>>>>    #define kvm__arch_get_kern_offset(...)    0x8000
> >>>>>> +struct kvm;
> >>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> >>>>>> +
> >>>>>>    #define ARM_MAX_MEMORY(...)    ARM_LOMAP_MAX_MEMORY
> >>>>>>    #define MAX_PAGE_SIZE    SZ_4K
> >>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> b/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> index 5e5ee41211ed..9124f6919d0f 100644
> >>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> @@ -6,6 +6,7 @@
> >>>>>>    struct kvm;
> >>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm,
> >>>>>> int fd);
> >>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
> >>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
> >>>>>>    #define ARM_MAX_MEMORY(kvm)    ({                    \
> >>>>>>        u64 max_ram;                            \
> >>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> b/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> index 04be43dfa9b2..11250365d8d5 100644
> >>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> @@ -6,6 +6,8 @@
> >>>>>>                "Run AArch32 guest"),                \
> >>>>>>        OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,            \
> >>>>>>                "Create PMUv3 device"),                \
> >>>>>> +    OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,            \
> >>>>>> +            "Enable memory tagging extension"),        \
> >>>>>>        OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,            \
> >>>>>>                "Specify random seed for Kernel Address Space "    \
> >>>>>>                "Layout Randomization (KASLR)"),
> >>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> >>>>>> index 56a0aedc263d..46548f8ee96e 100644
> >>>>>> --- a/arm/aarch64/kvm.c
> >>>>>> +++ b/arm/aarch64/kvm.c
> >>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> >>>>>>        return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> >>>>>>    }
> >>>>>> +
> >>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
> >>>>>> +{
> >>>>>> +    struct kvm_enable_cap cap = {
> >>>>>> +        .cap = KVM_CAP_ARM_MTE,
> >>>>>> +    };
> >>>>>> +
> >>>>>> +    if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> >>>>>> +        die("MTE capability is not supported");
> >>>>>> +
> >>>>>> +    if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> >>>>>> +        die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> >>>>>> +}
> >>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h
> >>>>>> b/arm/include/arm-common/kvm-config-arch.h
> >>>>>> index 5734c46ab9e6..16e8d500a71b 100644
> >>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
> >>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
> >>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
> >>>>>>        bool        virtio_trans_pci;
> >>>>>>        bool        aarch32_guest;
> >>>>>>        bool        has_pmuv3;
> >>>>>> +    bool        has_mte;
> >>>>>>        u64        kaslr_seed;
> >>>>>>        enum irqchip_type irqchip;
> >>>>>>        u64        fw_addr;
> >>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
> >>>>>> index 80d233f13d0b..f2db93953778 100644
> >>>>>> --- a/arm/kvm.c
> >>>>>> +++ b/arm/kvm.c
> >>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char
> >>>>>> *hugetlbfs_path, u64 ram_size)
> >>>>>>        /* Create the virtual GIC. */
> >>>>>>        if (gic__create(kvm, kvm->cfg.arch.irqchip))
> >>>>>>            die("Failed to create virtual GIC");
> >>>>>> +
> >>>>>> +    if (kvm->cfg.arch.has_mte)
> >>>>>> +        kvm__arch_enable_mte(kvm);
> >>>>>>    }
> >>>>>
> >>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported
> >>>>> like we do for
> >>>>> PAC and SVE?
> >>>>
> >>>> I thought about that, the reason I chose to enable it based a kvmtool
> >>>> command line option, instead of always being enabled if available, is
> >>>> because of the overhead of sanitising the MTE tags on each stage 2 data
> >>>> abort. Steven, am I overreacting and that overhead is negligible?
> >>>>
> >>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> >>>> until the guest starts to use those features.
> >>>>
> >>>> Do you have a specific reason for wanting MTE to always be enabled if
> >>>> available? I'm happy to be convinced to make MTE enabled by default, I
> >>>> don't have preference either way.
> >>>
> >>> Well, automatically enabling if available would align with what we do
> >>> for
> >>> other features in kvmtool and Linux itself - we tend to default y for
> >>> new
> >>> features, even MTE, thus improving chances to get reports back early if
> >>> something (even performance) goes wrong. Just my 2p.
> >>
> >> According to Steven, for each 4k page the kernel uses an 128 byte
> >> buffer to
> >> store the tags, and then some extra memory is used to keep track of the
> >> buffers. Let's take the case of a VM with 1GB of memory, and be
> >> conservative and only account for the tag buffer. In this case, the tag
> >> buffers alone will be 32MB.
> > 
> > Right, IIUC, that memory is allocated on demand when we about to swap
> > the page
> > out or perform hibernation, so there is no reservation done upfront or I'm
> > missing something?
> 
> That's correct, sorry if I didn't make that clear earlier. The host
> memory is only allocated when the MTE-enabled guest's pages are swapped
> out. So if they are never swapped out there's no memory overhead.
> 
> >>
> >> For a VM with 1GB of memory created with kvmtool built from current
> >> master
> >> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
> >> Subtracting the memory of the VM, we are left with 214MB of memory
> >> consumed
> >> by kvmtool. Having MTE enabled would increase the memory overhead of
> >> kvmtool by 32/214*100 = 15%.
> >>
> > 
> > I admit, I might be missing something, but given that extra tag storage
> > allocated for swap/hibernation overhead can be applied to any process which
> > uses MTE, no?
> 
> One difference is that the entire VM is considered MTE memory, whereas
> in a normal application only those pages mapped with PROT_MTE take the
> overhead. So the memory overhead of applications running in the VM is
> higher than the same application outside of the VM (assuming the memory
> is swapped out by the host).
> 
> >> Of course, this memory overhead scales with the amount of memory the VM
> >> has. The buffer size that KVM uses might change in the future, but
> >> since we
> >> cannot predict the future (might become larger or smaller), I'm working
> >> with what is implement today.
> >>
> > 
> > Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory
> > overhead
> > won't magically disappear, so should we start thinking how to reduce it?
> > I noticed that code saves tags one to one, so for guest which doesn't
> > actively use MTE whole page would be tagged with zero, cannot that case be
> > optimized? or maybe be go further and compress tags?
> 
> Compressing tags is certainly something that could be considered (an
> early revision of the MTE swap did optimise the zero case).
> 
> However Linux is lazy with the tags - if an application needs memory but
> doesn't use the tags then only the data portion will be zeroed and the
> tags will be left with whatever value they had previously (as they are
> not accessible by the application). This could mean that a MTE-enabled
> guest ends with with remarkably few pages with zeroed tags after it has
> been running for a while.
> 
> From the host it's not possible to determine whether the tags are useful
> or not so they have to be saved regardless.
> 
> That said I don't have a strong opinion on the default, as long as
> there's an option to disable MTE then having the default with it turned
> on is fine by me.
> 
> >> The kernel documentation for MTE suggests that in order to take advantage
> >> of it, software must be modified and recompiled. That means that users
> >> that
> >> don't want to use MTE won't get to exercise MTE because they won't be
> >> using
> >> MTE enabled software, but they will pay the overhead regardless. This of
> >> course assumes that going forward software won't be using MTE by default.
> >>
> >> kvmtool is supposed to be simple, fast and less resource intensive than
> >> other hypervisors, that's why I think having MTE disabled by default
> >> is the
> >> best way to implement the capability.
> > 
> > I see kvmtool as bleeding edge hacking tool, so closer it to the edge is
> > better :)
> 
> I have to admit I like the "just works" approach that the defaults give
> you (e.g. p9 filesystem from host, no need to configure root filesystems
> etc), so there's definitely something to be said for MTE "just working"
> in kvmtool too.
> 
> Steve

Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE

[Alexandru Elisei]

Hi,

Catalin, Steven, Vladimir, thank you all for the feedback. I'll make MTE
enabled by default in the next iteration of this series.

Thanks,
Alex

On Wed, Mar 23, 2022 at 02:15:55PM +0000, Steven Price wrote:
> On 23/03/2022 13:57, Vladimir Murzin wrote:
> > Hi,
> > 
> > On 3/23/22 12:03 PM, Alexandru Elisei wrote:
> >> Hi,
> >>
> >> On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote:
> >>> On 3/21/22 5:08 PM, Alexandru Elisei wrote:
> >>>> Hi,
> >>>>
> >>>> On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote:
> >>>>> Hi Alexandru,
> >>>>>
> >>>>> On 3/21/22 3:28 PM, Alexandru Elisei wrote:
> >>>>>> MTE has been supported in Linux since commit 673638f434ee ("KVM:
> >>>>>> arm64:
> >>>>>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool.
> >>>>>>
> >>>>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> >>>>>> ---
> >>>>>>    arm/aarch32/include/kvm/kvm-arch.h        |  3 +++
> >>>>>>    arm/aarch64/include/kvm/kvm-arch.h        |  1 +
> >>>>>>    arm/aarch64/include/kvm/kvm-config-arch.h |  2 ++
> >>>>>>    arm/aarch64/kvm.c                         | 13 +++++++++++++
> >>>>>>    arm/include/arm-common/kvm-config-arch.h  |  1 +
> >>>>>>    arm/kvm.c                                 |  3 +++
> >>>>>>    6 files changed, 23 insertions(+)
> >>>>>>
> >>>>>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> b/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> index bee2fc255a82..5616b27e257e 100644
> >>>>>> --- a/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> +++ b/arm/aarch32/include/kvm/kvm-arch.h
> >>>>>> @@ -5,6 +5,9 @@
> >>>>>>    #define kvm__arch_get_kern_offset(...)    0x8000
> >>>>>> +struct kvm;
> >>>>>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {}
> >>>>>> +
> >>>>>>    #define ARM_MAX_MEMORY(...)    ARM_LOMAP_MAX_MEMORY
> >>>>>>    #define MAX_PAGE_SIZE    SZ_4K
> >>>>>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> b/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> index 5e5ee41211ed..9124f6919d0f 100644
> >>>>>> --- a/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> +++ b/arm/aarch64/include/kvm/kvm-arch.h
> >>>>>> @@ -6,6 +6,7 @@
> >>>>>>    struct kvm;
> >>>>>>    unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm,
> >>>>>> int fd);
> >>>>>>    int kvm__arch_get_ipa_limit(struct kvm *kvm);
> >>>>>> +void kvm__arch_enable_mte(struct kvm *kvm);
> >>>>>>    #define ARM_MAX_MEMORY(kvm)    ({                    \
> >>>>>>        u64 max_ram;                            \
> >>>>>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> b/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> index 04be43dfa9b2..11250365d8d5 100644
> >>>>>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h
> >>>>>> @@ -6,6 +6,8 @@
> >>>>>>                "Run AArch32 guest"),                \
> >>>>>>        OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3,            \
> >>>>>>                "Create PMUv3 device"),                \
> >>>>>> +    OPT_BOOLEAN('\0', "mte", &(cfg)->has_mte,            \
> >>>>>> +            "Enable memory tagging extension"),        \
> >>>>>>        OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed,            \
> >>>>>>                "Specify random seed for Kernel Address Space "    \
> >>>>>>                "Layout Randomization (KASLR)"),
> >>>>>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c
> >>>>>> index 56a0aedc263d..46548f8ee96e 100644
> >>>>>> --- a/arm/aarch64/kvm.c
> >>>>>> +++ b/arm/aarch64/kvm.c
> >>>>>> @@ -81,3 +81,16 @@ int kvm__get_vm_type(struct kvm *kvm)
> >>>>>>        return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits);
> >>>>>>    }
> >>>>>> +
> >>>>>> +void kvm__arch_enable_mte(struct kvm *kvm)
> >>>>>> +{
> >>>>>> +    struct kvm_enable_cap cap = {
> >>>>>> +        .cap = KVM_CAP_ARM_MTE,
> >>>>>> +    };
> >>>>>> +
> >>>>>> +    if (!kvm__supports_extension(kvm, KVM_CAP_ARM_MTE))
> >>>>>> +        die("MTE capability is not supported");
> >>>>>> +
> >>>>>> +    if (ioctl(kvm->vm_fd, KVM_ENABLE_CAP, &cap))
> >>>>>> +        die_perror("KVM_ENABLE_CAP(KVM_CAP_ARM_MTE)");
> >>>>>> +}
> >>>>>> diff --git a/arm/include/arm-common/kvm-config-arch.h
> >>>>>> b/arm/include/arm-common/kvm-config-arch.h
> >>>>>> index 5734c46ab9e6..16e8d500a71b 100644
> >>>>>> --- a/arm/include/arm-common/kvm-config-arch.h
> >>>>>> +++ b/arm/include/arm-common/kvm-config-arch.h
> >>>>>> @@ -9,6 +9,7 @@ struct kvm_config_arch {
> >>>>>>        bool        virtio_trans_pci;
> >>>>>>        bool        aarch32_guest;
> >>>>>>        bool        has_pmuv3;
> >>>>>> +    bool        has_mte;
> >>>>>>        u64        kaslr_seed;
> >>>>>>        enum irqchip_type irqchip;
> >>>>>>        u64        fw_addr;
> >>>>>> diff --git a/arm/kvm.c b/arm/kvm.c
> >>>>>> index 80d233f13d0b..f2db93953778 100644
> >>>>>> --- a/arm/kvm.c
> >>>>>> +++ b/arm/kvm.c
> >>>>>> @@ -86,6 +86,9 @@ void kvm__arch_init(struct kvm *kvm, const char
> >>>>>> *hugetlbfs_path, u64 ram_size)
> >>>>>>        /* Create the virtual GIC. */
> >>>>>>        if (gic__create(kvm, kvm->cfg.arch.irqchip))
> >>>>>>            die("Failed to create virtual GIC");
> >>>>>> +
> >>>>>> +    if (kvm->cfg.arch.has_mte)
> >>>>>> +        kvm__arch_enable_mte(kvm);
> >>>>>>    }
> >>>>>
> >>>>> Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported
> >>>>> like we do for
> >>>>> PAC and SVE?
> >>>>
> >>>> I thought about that, the reason I chose to enable it based a kvmtool
> >>>> command line option, instead of always being enabled if available, is
> >>>> because of the overhead of sanitising the MTE tags on each stage 2 data
> >>>> abort. Steven, am I overreacting and that overhead is negligible?
> >>>>
> >>>> Also, as far as I know, PAC and SVE incur basically no overhead in KVM
> >>>> until the guest starts to use those features.
> >>>>
> >>>> Do you have a specific reason for wanting MTE to always be enabled if
> >>>> available? I'm happy to be convinced to make MTE enabled by default, I
> >>>> don't have preference either way.
> >>>
> >>> Well, automatically enabling if available would align with what we do
> >>> for
> >>> other features in kvmtool and Linux itself - we tend to default y for
> >>> new
> >>> features, even MTE, thus improving chances to get reports back early if
> >>> something (even performance) goes wrong. Just my 2p.
> >>
> >> According to Steven, for each 4k page the kernel uses an 128 byte
> >> buffer to
> >> store the tags, and then some extra memory is used to keep track of the
> >> buffers. Let's take the case of a VM with 1GB of memory, and be
> >> conservative and only account for the tag buffer. In this case, the tag
> >> buffers alone will be 32MB.
> > 
> > Right, IIUC, that memory is allocated on demand when we about to swap
> > the page
> > out or perform hibernation, so there is no reservation done upfront or I'm
> > missing something?
> 
> That's correct, sorry if I didn't make that clear earlier. The host
> memory is only allocated when the MTE-enabled guest's pages are swapped
> out. So if they are never swapped out there's no memory overhead.
> 
> >>
> >> For a VM with 1GB of memory created with kvmtool built from current
> >> master
> >> (commit faae833a746f), pmap shows a total memory usage of 1268388K.
> >> Subtracting the memory of the VM, we are left with 214MB of memory
> >> consumed
> >> by kvmtool. Having MTE enabled would increase the memory overhead of
> >> kvmtool by 32/214*100 = 15%.
> >>
> > 
> > I admit, I might be missing something, but given that extra tag storage
> > allocated for swap/hibernation overhead can be applied to any process which
> > uses MTE, no?
> 
> One difference is that the entire VM is considered MTE memory, whereas
> in a normal application only those pages mapped with PROT_MTE take the
> overhead. So the memory overhead of applications running in the VM is
> higher than the same application outside of the VM (assuming the memory
> is swapped out by the host).
> 
> >> Of course, this memory overhead scales with the amount of memory the VM
> >> has. The buffer size that KVM uses might change in the future, but
> >> since we
> >> cannot predict the future (might become larger or smaller), I'm working
> >> with what is implement today.
> >>
> > 
> > Fair enough. IMO, we will see more MTE capable hardware, OTOH, memory
> > overhead
> > won't magically disappear, so should we start thinking how to reduce it?
> > I noticed that code saves tags one to one, so for guest which doesn't
> > actively use MTE whole page would be tagged with zero, cannot that case be
> > optimized? or maybe be go further and compress tags?
> 
> Compressing tags is certainly something that could be considered (an
> early revision of the MTE swap did optimise the zero case).
> 
> However Linux is lazy with the tags - if an application needs memory but
> doesn't use the tags then only the data portion will be zeroed and the
> tags will be left with whatever value they had previously (as they are
> not accessible by the application). This could mean that a MTE-enabled
> guest ends with with remarkably few pages with zeroed tags after it has
> been running for a while.
> 
> From the host it's not possible to determine whether the tags are useful
> or not so they have to be saved regardless.
> 
> That said I don't have a strong opinion on the default, as long as
> there's an option to disable MTE then having the default with it turned
> on is fine by me.
> 
> >> The kernel documentation for MTE suggests that in order to take advantage
> >> of it, software must be modified and recompiled. That means that users
> >> that
> >> don't want to use MTE won't get to exercise MTE because they won't be
> >> using
> >> MTE enabled software, but they will pay the overhead regardless. This of
> >> course assumes that going forward software won't be using MTE by default.
> >>
> >> kvmtool is supposed to be simple, fast and less resource intensive than
> >> other hypervisors, that's why I think having MTE disabled by default
> >> is the
> >> best way to implement the capability.
> > 
> > I see kvmtool as bleeding edge hacking tool, so closer it to the edge is
> > better :)
> 
> I have to admit I like the "just works" approach that the defaults give
> you (e.g. p9 filesystem from host, no need to configure root filesystems
> etc), so there's definitely something to be said for MTE "just working"
> in kvmtool too.
> 
> Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel