[PATCH 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

Introduce a new KVM capability, KVM_CAP_PPC_HTM, that can be queried to
determine if a PowerPC KVM guest should use HTM (Hardware Transactional
Memory).

This will be used by QEMU to populate the pa-features bits in the
guest's device tree.

Signed-off-by: Sam Bobroff <redacted>
---

 arch/powerpc/kvm/powerpc.c | 4 ++++
 include/uapi/linux/kvm.h   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 02416fe..06d79bc 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c

@@ -588,6 +588,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		r = 1;
 		break;
 #endif
+	case KVM_CAP_PPC_HTM:
+		r = cpu_has_feature(CPU_FTR_TM)
+		    && is_kvmppc_hv_enabled(kvm);
+		break;
 	default:
 		r = 0;
 		break;

diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 05ebf47..f421d0e 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h

@@ -866,6 +866,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_PMU_V3 126
 #define KVM_CAP_VCPU_ATTRIBUTES 127
 #define KVM_CAP_MAX_VCPU_ID 128
+#define KVM_CAP_PPC_HTM 129
 
 #ifdef KVM_CAP_IRQ_ROUTING
 

-- 
2.1.0

On Wed, 2016-07-06 at 16:05 +1000, Sam Bobroff wrote:

Introduce a new KVM capability, KVM_CAP_PPC_HTM, that can be queried to
determine if a PowerPC KVM guest should use HTM (Hardware Transactional
Memory).

This will be used by QEMU to populate the pa-features bits in the
guest's device tree.

Signed-off-by: Sam Bobroff <redacted>
---

Makes sense

Acked-by: Balbir Singh <bsingharora@gmail.com>

On Wed, Jul 06, 2016 at 04:05:54PM +1000, Sam Bobroff wrote:

Introduce a new KVM capability, KVM_CAP_PPC_HTM, that can be queried to
determine if a PowerPC KVM guest should use HTM (Hardware Transactional
Memory).

This will be used by QEMU to populate the pa-features bits in the
guest's device tree.

Signed-off-by: Sam Bobroff <redacted>

Reviewed-by: David Gibson <redacted>

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:

I think it should be using CPU_FTR_TM_COMP.

And AFAICS you don't need to break that line.

cheers

On Fri, Jul 08, 2016 at 08:49:49PM +1000, Michael Ellerman wrote:

On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:

quoted

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 02416fe..06d79bc 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c

@@ -588,6 +588,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		r = 1;
 		break;
 #endif
+	case KVM_CAP_PPC_HTM:
+		r = cpu_has_feature(CPU_FTR_TM)
+		    && is_kvmppc_hv_enabled(kvm);

I think it should be using CPU_FTR_TM_COMP.

Oh, why is that? I'm happy to respin the patch I'm just curious.

(I did it that way becuase that seems to be the way the other flags are used,
e.g. CPU_FTR_ALTIVEC).

If I read the code correctly, using CPU_FTR_TM_COMP will work fine: it should
cause the cpu_has_feature() test to always return false if CPU_FTR_TM_COMP is
0.

And AFAICS you don't need to break that line.

Sure, I'll un-split it when I respin.

cheers

Cheers,
Sam.

Sam Bobroff [off-list ref] writes:

On Fri, Jul 08, 2016 at 08:49:49PM +1000, Michael Ellerman wrote:

quoted

On Wed, 2016-06-07 at 06:05:54 UTC, Sam bobroff wrote:

quoted

diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 02416fe..06d79bc 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c

@@ -588,6 +588,10 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 		r = 1;
 		break;
 #endif
+	case KVM_CAP_PPC_HTM:
+		r = cpu_has_feature(CPU_FTR_TM)
+		    && is_kvmppc_hv_enabled(kvm);

I think it should be using CPU_FTR_TM_COMP.

Oh, why is that? I'm happy to respin the patch I'm just curious.

(I did it that way becuase that seems to be the way the other flags are used,
e.g. CPU_FTR_ALTIVEC).

If I read the code correctly, using CPU_FTR_TM_COMP will work fine: it should
cause the cpu_has_feature() test to always return false if CPU_FTR_TM_COMP is
0.

CPU_FTR_TM says the CPU supports TM.

CPU_FTR_TM_COMP says the CPU supports TM *and* the kernel is built with
TM support.

The distinction exists because currently the assembly patching macros
don't deal correctly with a feature bit that is defined to 0. (And
possibly other reasons I don't remember)

We should fix that, but until we have, anything that is advertising
support to userspace should be using the COMP bits, when they exist.

cheers