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

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

[Sam Bobroff]

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 <sam.bobroff@au1.ibm.com>
---

v2:

* Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
* I didn't unbreak the line, as with the extra characters checkpatch will
  complain if I do. I did move the break to a more usual place.

 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..5ebc8ff 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_COMP) &&
+		    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

[Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Sam Bobroff]

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 <sam.bobroff@au1.ibm.com>
---

v2:

* Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
* I didn't unbreak the line, as with the extra characters checkpatch will
  complain if I do. I did move the break to a more usual place.

 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..5ebc8ff 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_COMP) &&
+		    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

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

[Sam Bobroff]

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 <sam.bobroff@au1.ibm.com>
---

v2:

* Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
* I didn't unbreak the line, as with the extra characters checkpatch will
  complain if I do. I did move the break to a more usual place.

 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..5ebc8ff 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_COMP) &&
+		    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

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

[Balbir Singh]

On 20/07/16 13:41, 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 <sam.bobroff@au1.ibm.com>
> ---
> 
Make sense

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

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Balbir Singh]

On 20/07/16 13:41, 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 <sam.bobroff@au1.ibm.com>
> ---
> 
Make sense

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

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

[Balbir Singh]

On 20/07/16 13:41, 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 <sam.bobroff@au1.ibm.com>
> ---
> 
Make sense

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

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

[Michael Ellerman]

Sam Bobroff <sam.bobroff@au1.ibm.com> writes:

> 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

Minor nit, "should" should be "can" IMHO.

> Memory).
>
> This will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.

Thanks.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

Or do you want me to merge this before Paul gets back?

> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.

I would just ignore checkpatch. But I don't mind that much.

cheers

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Michael Ellerman]

Sam Bobroff <sam.bobroff@au1.ibm.com> writes:

> 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

Minor nit, "should" should be "can" IMHO.

> Memory).
>
> This will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.

Thanks.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

Or do you want me to merge this before Paul gets back?

> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.

I would just ignore checkpatch. But I don't mind that much.

cheers

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

[Michael Ellerman]

Sam Bobroff <sam.bobroff@au1.ibm.com> writes:

> 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

Minor nit, "should" should be "can" IMHO.

> Memory).
>
> This will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.

Thanks.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

Or do you want me to merge this before Paul gets back?

> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.

I would just ignore checkpatch. But I don't mind that much.

cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Paolo Bonzini]

On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Paolo Bonzini]

On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

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

[Paolo Bonzini]

On 20/07/2016 07:46, Michael Ellerman wrote:
> Thanks.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> Or do you want me to merge this before Paul gets back?

No, this should be merged through the KVM tree.  Please Cc the KVM
maintainers before offering to apply a patch that formally belongs to
another tree.

I don't care if Paul merges the patch or Radim and I do, but we're
getting lots of unnecessary conflicts from patches that go through the
main architecture tree and that shouldn't really happen.  Please let's
keep some discipline, as I want to minimize the number of conflicts that
reach Linus (and 4.8 is going to be *bad* in this respect, with both PPC
and s390 having conflicts between the KVM and arch tree).

In particular this patch would indeed have a conflict, because you have

+#define KVM_CAP_PPC_HTM 129

but cap numbers 129 and 130 are already taken.  So whoever applies it
should bump the number to 131.

Paolo

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

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>> 
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> 
>> Or do you want me to merge this before Paul gets back?
>
> No, this should be merged through the KVM tree.  Please Cc the KVM
> maintainers before offering to apply a patch that formally belongs to
> another tree.

Yeah OK. It was just an offer, because I know the Qemu side is blocked
until this goes in.

> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Yep, I know about KVM caps, I probably would have remembered to check
the KVM tree. At the very least it would have got caught in linux-next.

cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>> 
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> 
>> Or do you want me to merge this before Paul gets back?
>
> No, this should be merged through the KVM tree.  Please Cc the KVM
> maintainers before offering to apply a patch that formally belongs to
> another tree.

Yeah OK. It was just an offer, because I know the Qemu side is blocked
until this goes in.

> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Yep, I know about KVM caps, I probably would have remembered to check
the KVM tree. At the very least it would have got caught in linux-next.

cheers

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

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>> 
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> 
>> Or do you want me to merge this before Paul gets back?
>
> No, this should be merged through the KVM tree.  Please Cc the KVM
> maintainers before offering to apply a patch that formally belongs to
> another tree.

Yeah OK. It was just an offer, because I know the Qemu side is blocked
until this goes in.

> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Yep, I know about KVM caps, I probably would have remembered to check
the KVM tree. At the very least it would have got caught in linux-next.

cheers

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>> 
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> 
>> Or do you want me to merge this before Paul gets back?
>
> No, this should be merged through the KVM tree.  Please Cc the KVM
> maintainers before offering to apply a patch that formally belongs to
> another tree.

Yeah OK. It was just an offer, because I know the Qemu side is blocked
until this goes in.

> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Yep, I know about KVM caps, I probably would have remembered to check
the KVM tree. At the very least it would have got caught in linux-next.

cheers

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

[Michael Ellerman]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 20/07/2016 07:46, Michael Ellerman wrote:
>> Thanks.
>> 
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> 
>> Or do you want me to merge this before Paul gets back?
>
> No, this should be merged through the KVM tree.  Please Cc the KVM
> maintainers before offering to apply a patch that formally belongs to
> another tree.

Yeah OK. It was just an offer, because I know the Qemu side is blocked
until this goes in.

> In particular this patch would indeed have a conflict, because you have
>
> +#define KVM_CAP_PPC_HTM 129
>
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Yep, I know about KVM caps, I probably would have remembered to check
the KVM tree. At the very least it would have got caught in linux-next.

cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[Paolo Bonzini]

On 20/07/2016 08:30, Paolo Bonzini wrote:
> In particular this patch would indeed have a conflict, because you have
> 
> +#define KVM_CAP_PPC_HTM 129
> 
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Applied now, it's 132.

Paolo

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Paolo Bonzini]

On 20/07/2016 08:30, Paolo Bonzini wrote:
> In particular this patch would indeed have a conflict, because you have
> 
> +#define KVM_CAP_PPC_HTM 129
> 
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Applied now, it's 132.

Paolo

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

[Paolo Bonzini]

On 20/07/2016 08:30, Paolo Bonzini wrote:
> In particular this patch would indeed have a conflict, because you have
> 
> +#define KVM_CAP_PPC_HTM 129
> 
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Applied now, it's 132.

Paolo

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

[Paolo Bonzini]

On 20/07/2016 08:30, Paolo Bonzini wrote:
> In particular this patch would indeed have a conflict, because you have
> 
> +#define KVM_CAP_PPC_HTM 129
> 
> but cap numbers 129 and 130 are already taken.  So whoever applies it
> should bump the number to 131.

Applied now, it's 132.

Paolo

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

[Michael Ellerman]

Sam Bobroff <sam.bobroff@au1.ibm.com> writes:

> 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

Minor nit, "should" should be "can" IMHO.

> Memory).
>
> This will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.

Thanks.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

Or do you want me to merge this before Paul gets back?

> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.

I would just ignore checkpatch. But I don't mind that much.

cheers

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

[Michael Ellerman]

Sam Bobroff <sam.bobroff@au1.ibm.com> writes:

> 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

Minor nit, "should" should be "can" IMHO.

> Memory).
>
> This will be used by QEMU to populate the pa-features bits in the
> guest's device tree.
>
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
>
> v2:
>
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.

Thanks.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

Or do you want me to merge this before Paul gets back?

> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.

I would just ignore checkpatch. But I don't mind that much.

cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Wed, Jul 20, 2016 at 01:41:36PM +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 <sam.bobroff@au1.ibm.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
> 
> v2:
> 
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.
> 
>  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..5ebc8ff 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_COMP) &&
> +		    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
>  

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [PATCH v2 1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Wed, Jul 20, 2016 at 01:41:36PM +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 <sam.bobroff@au1.ibm.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
> 
> v2:
> 
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.
> 
>  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..5ebc8ff 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_COMP) &&
> +		    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
>  

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Wed, Jul 20, 2016 at 01:41:36PM +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 <sam.bobroff@au1.ibm.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

> ---
> 
> v2:
> 
> * Use CPU_FTR_TM_COMP instead of CPU_FTR_TM.
> * I didn't unbreak the line, as with the extra characters checkpatch will
>   complain if I do. I did move the break to a more usual place.
> 
>  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..5ebc8ff 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_COMP) &&
> +		    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
>  

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]