[1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM

[Michael Ellerman]

Sam Bobroff <sam.bobroff at 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