[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH] i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and HV_CPUID_NESTED_FEATURES.EAX as feature words |
Date: |
Fri, 30 Nov 2018 16:36:08 -0200 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Thu, Nov 29, 2018 at 12:51:55PM +0100, Vitaly Kuznetsov wrote:
> Paolo Bonzini <address@hidden> writes:
>
> > On 26/11/18 14:59, Vitaly Kuznetsov wrote:
> >> It was found that QMP users of QEMU (e.g. libvirt) may need
> >> HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
> >> particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
> >> HV_CPUID_ENLIGHTMENT_INFO.EAX.
> >>
> >> HV_CPUID_NESTED_FEATURES.EAX is exposed for two reasons: convenience
> >> (we don't need to export it from hyperv_handle_properties() and as
> >> future-proof for Enlightened MSR-Bitmap, PV EPT invalidation and
> >> direct virtual flush features.
> >>
> >> Signed-off-by: Vitaly Kuznetsov <address@hidden>
> >
> > Can you add a comment to feature_word_info, explaining why the
> > feat_names are not set?
>
> I had to do some code archeology to make sure I understand, I think it
> goes back to
>
> http://lists.gnu.org/archive/html/qemu-devel/2016-06/msg06579.html
>
> So the comment (probably added before FEAT_HYPERV_EAX definition) would
> be
>
> ".feat_names are commented out for Hyper-V enlightenments because we
> don't want to have two different ways for enabling them on QEMU command
> line. Some features (e.g. "hyperv_time", "hyperv_vapic", ...) require
> enabling several feature bits simultaneously, exposing these bits
> individually may just confuse guests."
>
> Would do?
That's an accurate description.
But note that we might still be able to move the existing
"hyperv_*" features to feature_word_info[].feat_names. We just
need to keep the same semantics (e.g. enable
HV_HYPERCALL_AVAILABLE automatically when some features are set).
Maybe we can make some of the feature properties read-only. This
way we can give them meaningful names for debugging and error
messages, even if we don't want to make them configurable
directly.
--
Eduardo