From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH v2 0/7] x86/kvm/hyper-v: Implement KVM_GET_SUPPORTED_HV_CPUID Date: Tue, 18 Dec 2018 09:16:04 +0100 Message-ID: <87k1k72qt7.fsf@vitty.brq.redhat.com> References: <20181210172159.410-1-vkuznets@redhat.com> <7a318d1c-7601-fc67-8924-971f9deb8824@redhat.com> <87woo830o6.fsf@vitty.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, Roman Kagan , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , x86@kernel.org, "Michael Kelley \(EOSG\)" , Eduardo Habkost To: Paolo Bonzini , kvm@vger.kernel.org Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Paolo Bonzini writes: > On 17/12/18 11:30, Vitaly Kuznetsov wrote: >>> Queued, thanks. I moved this above the direct EOI series so that >>> KVM_CAP_HYPERV_STIMER_DIRECT need not exist at any point of the history. >>> >> Thanks! Just to make sure (and to conclude our discussion with Roman): >> with your Qemu maintainer hat on, do you agree with the design decision >> that KVM_GET_SUPPORTED_HV_CPUID's output value changes when >> KVM_CAP_HYPERV_ENLIGHTENED_VMCS gets enabled? This differs from >> KVM_GET_SUPPORTED_CPUID (where we always list all feature bits even if >> they require explicit enablement)? > > It doesn't really matter, since the old capability cannot be removed. > If you want to change it with a patch on top, that's also okay with me. Ok, let's leave it as it is: maybe some other userspace (which doesn't use legacy capabilities) will be grateful :-) -- Vitaly