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: <87r191jqh9.fsf@redhat.com>
Date:   Fri, 21 Jan 2022 12:08:34 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: skip host CPUID call for hypervisor leaves

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

> Hypervisor leaves are always synthesized by __do_cpuid_func.  Just return
> zeroes and do not ask the host, it would return a bogus value anyway if
> it were used.

Why always bogus? Nested virtualization is a thing, isn't it? :-) It
is, however, true that __do_cpuid_func() will throw the result away.

>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  arch/x86/kvm/cpuid.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 3902c28fb6cb..fd949e89120a 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -692,9 +692,17 @@ static struct kvm_cpuid_entry2 *do_host_cpuid(struct kvm_cpuid_array *array,
>  
>  	entry = &array->entries[array->nent++];
>  
> +	memset(entry, 0, sizeof(*entry));
>  	entry->function = function;
>  	entry->index = index;
> -	entry->flags = 0;
> +	switch (function & 0xC0000000) {
> +	case 0x40000000:
> +		/* Hypervisor leaves are always synthesized by __do_cpuid_func.  */
> +		return entry;

FWIW, 0x40000XXX leaves are not the only ones where we don't use
do_host_cpuid() result at all, e.g. I can see that we also return
constant values for 0x3, 0x5, 0x6, 0xC0000002 - 0xC0000004. 

Out of pure curiosity, what's the motivation for the patch? We seem to
only use __do_cpuid_func() to serve KVM_GET_SUPPORTED_CPUID/KVM_GET_EMULATED_CPUID,
not for kvm_emulate_cpuid() so these few CPUID calls we save here should
not give us any performace gain..

> +
> +	default:
> +		break;
> +	}
>  
>  	cpuid_count(entry->function, entry->index,
>  		    &entry->eax, &entry->ebx, &entry->ecx, &entry->edx);

The patch seems to be correct, so

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

-- 
Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ