| Message ID | 7286403003b30fc87740f1c1d6cb67d8f8eaafd7.1468986094.git.sam.bobroff@au1.ibm.com |
|---|---|
| State | New |
| Headers | show |
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>
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
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
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 >
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
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
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(+)