[1/1] KVM: PPC: Introduce KVM_CAP_PPC_HTM
mpe at ellerman.id.au
Tue Jul 19 19:24:46 AEST 2016
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
CPU_FTR_TM says the CPU supports TM.
CPU_FTR_TM_COMP says the CPU supports TM *and* the kernel is built with
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.
More information about the Linuxppc-dev