From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH RFC 22/22] i386: expand Hyper-V features early
Date: Tue, 22 Sep 2020 12:37:01 +0200 [thread overview]
Message-ID: <878sd2f67m.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200918224721.GL57321@habkost.net>
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Fri, Sep 04, 2020 at 04:54:31PM +0200, Vitaly Kuznetsov wrote:
>> To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we
>> need to expand and set the corresponding CPUID leaves early. Modify
>> x86_cpu_get_supported_feature_word() to call newly intoduced Hyper-V
>> specific kvm_hv_get_supported_cpuid() instead of
>> kvm_arch_get_supported_cpuid(). We can't use kvm_arch_get_supported_cpuid()
>> as Hyper-V specific CPUID leaves intersect with KVM's.
>>
>> Note, early expansion will only happen when KVM supports system wide
>> KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
> [...]
>> +uint32_t kvm_hv_get_supported_cpuid(X86CPU *cpu, enum FeatureWord w)
>> +{
>> + CPUState *cs = CPU(cpu);
>> + CPUX86State *env = &cpu->env;
>> + Error *local_err = NULL;
>> +
>> + hyperv_expand_features(cs, &local_err);
>
> This makes a function that sounds like it doesn't have any side
> effect ("get supported cpuid") have an unintended side effect
> (hyperv_expand_features() will change all CPUID data inside the
> cpu object).
>
> What about making it more similar to
> kvm_arch_get_supported_cpuid(), and be just a wrapper to
> get_supported_hv_cpuid()?
>
> I would also make sure get_supported_hv_cpuid() doesn't get
> CPUState as argument, just to be sure it will never touch the CPU
> object state.
Sure, I can try. The difference with get_supported_cpuid() is that
get_supported_hv_cpuid() currently doesn't have cache and we don't
probably want to call KVM_GET_SUPPORTED_HV_CPUID ioctl for every CPUID
leaf. I don't see why it can't be introduced though.
>
>> +
>> + if (local_err) {
>> + error_report_err(local_err);
>> + }
>> +
>> + return env->features[w];
>> +}
>> +
>> static Error *hv_passthrough_mig_blocker;
>> static Error *hv_no_nonarch_cs_mig_blocker;
>>
>> diff --git a/target/i386/kvm_i386.h b/target/i386/kvm_i386.h
>> index 064b8798a26c..2e7da4f39668 100644
>> --- a/target/i386/kvm_i386.h
>> +++ b/target/i386/kvm_i386.h
>> @@ -48,4 +48,11 @@ bool kvm_has_waitpkg(void);
>>
>> bool kvm_hv_vpindex_settable(void);
>>
>> +static inline bool hyperv_feature_word(enum FeatureWord w)
>> +{
>> + return w >= FEAT_HYPERV_EAX && w <= FEAT_HV_NESTED_EDX;
>> +}
>> +
>> +uint32_t kvm_hv_get_supported_cpuid(X86CPU *cpu, enum FeatureWord w);
>> +
>> #endif
>> --
>> 2.25.4
>>
--
Vitaly
prev parent reply other threads:[~2020-09-22 10:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 14:54 [PATCH RFC 00/22] i386: KVM: expand Hyper-V features early Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 01/22] WIP: update linux/headers Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 02/22] i386: drop x86_cpu_get_supported_feature_word() forward declaration Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 03/22] i386: move hyperv_vendor_id initialization to x86_cpu_realizefn() Vitaly Kuznetsov
2020-09-18 22:14 ` Eduardo Habkost
2020-09-22 10:23 ` Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 04/22] i386: move hyperv_interface_id " Vitaly Kuznetsov
2020-09-18 22:23 ` Eduardo Habkost
2020-09-04 14:54 ` [PATCH RFC 05/22] i386: move hyperv_version_id " Vitaly Kuznetsov
2020-09-18 22:15 ` Eduardo Habkost
2020-09-04 14:54 ` [PATCH RFC 06/22] i386: move hyperv_limits " Vitaly Kuznetsov
2020-09-18 22:16 ` Eduardo Habkost
2020-09-04 14:54 ` [PATCH RFC 07/22] i386: fill in FEAT_HYPERV_EDX from edx instead of eax Vitaly Kuznetsov
2020-09-18 22:21 ` Eduardo Habkost
2020-09-04 14:54 ` [PATCH RFC 08/22] i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 09/22] i386: add reserved FEAT_HYPERV_ECX CPUID leaf Vitaly Kuznetsov
2020-09-18 22:25 ` Eduardo Habkost
2020-09-22 10:27 ` Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 10/22] i386: add reserved FEAT_HV_RECOMM_ECX/FEAT_HV_RECOMM_EDX CPUID leaves Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 11/22] i386: add reserved FEAT_HV_NESTED_EBX/ECX/EDX " Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 12/22] i386: always fill Hyper-V CPUID feature leaves from X86CPU data Vitaly Kuznetsov
2020-09-18 22:32 ` Eduardo Habkost
2020-09-22 10:30 ` Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 13/22] i386: split hyperv_handle_properties() into hyperv_expand_features()/hyperv_fill_cpuids() Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 14/22] i386: move eVMCS enablement to hyperv_init_vcpu() Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 15/22] i386: switch hyperv_expand_features() to using error_setg() Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 16/22] i386: make hyperv_expand_features() return void Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 17/22] i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 18/22] i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 19/22] i386: prepare hyperv_expand_features() to be called at CPU feature expansion time Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 20/22] i386: use global kvm_state in hyperv_enabled() check Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 21/22] i386: record if Hyper-V features were already expanded Vitaly Kuznetsov
2020-09-04 14:54 ` [PATCH RFC 22/22] i386: expand Hyper-V features early Vitaly Kuznetsov
2020-09-18 22:38 ` Eduardo Habkost
2020-09-22 10:33 ` Vitaly Kuznetsov
2020-09-18 22:47 ` Eduardo Habkost
2020-09-22 10:37 ` Vitaly Kuznetsov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878sd2f67m.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.