Sam Bobroff <sam.bobr...@au1.ibm.com> writes: > 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: >> > 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
