[<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