linux-kernel - Re: [PATCH] KVM: X86: correct meaningless kvm_apicv

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: <878sk0n1g1.fsf@vitty.brq.redhat.com>
Date:   Mon, 16 Mar 2020 09:33:50 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linmiaohe@...wei.com, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: X86: correct meaningless kvm_apicv_activated() check

Paolo Bonzini <pbonzini@...hat.com> writes:

> After test_and_set_bit() for kvm->arch.apicv_inhibit_reasons, we will
> always get false when calling kvm_apicv_activated() because it's sure
> apicv_inhibit_reasons do not equal to 0.
>
> What the code wants to do, is check whether APICv was *already* active
> and if so skip the costly request; we can do this using cmpxchg.
>
> Reported-by: Miaohe Lin <linmiaohe@...wei.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/x86.c | 25 ++++++++++++++++---------
>  1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a7cb85231330..49efa4529662 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8049,19 +8049,26 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
>   */
>  void kvm_request_apicv_update(struct kvm *kvm, bool activate, ulong bit)
>  {
> +	unsigned long old, new, expected;
> +
>  	if (!kvm_x86_ops->check_apicv_inhibit_reasons ||
>  	    !kvm_x86_ops->check_apicv_inhibit_reasons(bit))
>  		return;
>  
> -	if (activate) {
> -		if (!test_and_clear_bit(bit, &kvm->arch.apicv_inhibit_reasons) ||
> -		    !kvm_apicv_activated(kvm))
> -			return;
> -	} else {
> -		if (test_and_set_bit(bit, &kvm->arch.apicv_inhibit_reasons) ||
> -		    kvm_apicv_activated(kvm))
> -			return;
> -	}
> +	old = READ_ONCE(kvm->arch.apicv_inhibit_reasons);
> +	do {
> +		expected = new = old;
> +		if (activate)
> +			__clear_bit(bit, &new);
> +		else
> +			__set_bit(bit, &new);
> +		if (new == old)
> +			break;
> +		old = cmpxchg(&kvm->arch.apicv_inhibit_reasons, expected, new);
> +	} while (old != expected);

'expected' here is a bit confusing as it's not what we expect to get as
the result but rather what we expect to see pre-change. I don't have a
better suggestion though.

> +
> +	if ((old == 0) == (new == 0))
> +		return;

This is a very laconic expression I personally find hard to read :-)

	/* Check if WE actually changed APICv state */
        if ((!old && !new) || (old && new))
		return;

would be my preference (not strong though, I read yours several times
and now I feel like I understand it just fine :-)

>  
>  	trace_kvm_apicv_update_request(activate, bit);
>  	if (kvm_x86_ops->pre_update_apicv_exec_ctrl)

Reviewed-by: Vitaly Kuznetsov <vkuznets@...hat.com>

-- 
Vitaly