lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f99a6a2-b64e-0211-a7d3-8b84c668a92f@redhat.com>
Date:   Fri, 18 Feb 2022 18:20:17 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v3 6/6] KVM: x86: allow defining return-0 static calls

On 2/18/22 17:29, Sean Christopherson wrote:
> On Thu, Feb 17, 2022, Paolo Bonzini wrote:
>> A few vendor callbacks are only used by VMX, but they return an integer
>> or bool value.  Introduce KVM_X86_OP_OPTIONAL_RET0 for them: if a func is
>> NULL in struct kvm_x86_ops, it will be changed to __static_call_return0
>> when updating static calls.
>>
>> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
>> ---
>>   arch/x86/include/asm/kvm-x86-ops.h | 15 +++++++++------
>>   arch/x86/include/asm/kvm_host.h    |  4 ++++
>>   arch/x86/kvm/svm/avic.c            |  5 -----
>>   arch/x86/kvm/svm/svm.c             | 20 --------------------
>>   arch/x86/kvm/x86.c                 |  2 +-
>>   kernel/static_call.c               |  1 +
>>   6 files changed, 15 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h
>> index c0ec066a8599..29affccb353c 100644
>> --- a/arch/x86/include/asm/kvm-x86-ops.h
>> +++ b/arch/x86/include/asm/kvm-x86-ops.h
>> @@ -10,7 +10,9 @@ BUILD_BUG_ON(1)
>>    *
>>    * KVM_X86_OP_OPTIONAL() can be used for those functions that can have
>>    * a NULL definition, for example if "static_call_cond()" will be used
>> - * at the call sites.
>> + * at the call sites.  KVM_X86_OP_OPTIONAL_RET0() can be used likewise
>> + * to make a definition optional, but in this case the default will
>> + * be __static_call_return0.
> 
> __static_call_return0()
> 
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index ab1c4778824a..d3da64106685 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -131,6 +131,7 @@ struct kvm_x86_ops kvm_x86_ops __read_mostly;
>>   	DEFINE_STATIC_CALL_NULL(kvm_x86_##func,			     \
>>   				*(((struct kvm_x86_ops *)0)->func));
>>   #define KVM_X86_OP_OPTIONAL KVM_X86_OP
>> +#define KVM_X86_OP_OPTIONAL_RET0 KVM_X86_OP
>>   #include <asm/kvm-x86-ops.h>
>>   EXPORT_STATIC_CALL_GPL(kvm_x86_get_cs_db_l_bits);
>>   EXPORT_STATIC_CALL_GPL(kvm_x86_cache_reg);
>> @@ -12016,7 +12017,6 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm,
>>   static inline bool kvm_guest_apic_has_interrupt(struct kvm_vcpu *vcpu)
>>   {
>>   	return (is_guest_mode(vcpu) &&
>> -			kvm_x86_ops.guest_apic_has_interrupt &&
>>   			static_call(kvm_x86_guest_apic_has_interrupt)(vcpu));
> 
> Can you opportunistically align the indentation and drop the outer parantheses? I.e.
> 
> 	return is_guest_mode(vcpu) &&
> 	       static_call(kvm_x86_guest_apic_has_interrupt)(vcpu);

Hmm, I like having the parentheses (despite "return not being a 
function") because editors are inconsistent in what indentation to use 
after return.

Some use a tab (which does the right thing just by chance with Linux 
because "return " is as long as a tab is wide), but vim for example does 
the totally awkward

int f()
{
         return a &&
                 b;
}

Of course I can fix the indentation.

Paolo

>>   }
>>   
>> diff --git a/kernel/static_call.c b/kernel/static_call.c
>> index 43ba0b1e0edb..76abd46fe6ee 100644
>> --- a/kernel/static_call.c
>> +++ b/kernel/static_call.c
>> @@ -503,6 +503,7 @@ long __static_call_return0(void)
>>   {
>>   	return 0;
>>   }
>> +EXPORT_SYMBOL_GPL(__static_call_return0)
> 
> This doesn't compile, it needs a semicolon.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ