Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Vitaly Kuznetsov <vkuznets@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Cc:     Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        linux-kernel@vger.kernel.org, Roman Kagan <rkagan@virtuozzo.com>,
        "K. Y. Srinivasan" <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>, x86@kernel.org,
        "Michael Kelley \(EOSG\)" <Michael.H.Kelley@microsoft.com>
Subject: Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers
In-Reply-To: <e565638e-d6cc-bbd9-f99e-c835ef1be5b7@redhat.com>
References: <20181126154732.23025-1-vkuznets@redhat.com> <20181126154732.23025-4-vkuznets@redhat.com> <e565638e-d6cc-bbd9-f99e-c835ef1be5b7@redhat.com>
Date:   Mon, 26 Nov 2018 18:14:49 +0100
Message-ID: <8736rnlq0m.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Paolo Bonzini <pbonzini@redhat.com> writes:

>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 2b7a652c9fa4..b8da14cee8e5 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -975,6 +975,7 @@ struct kvm_ppc_resize_hpt {
>>  #define KVM_CAP_HYPERV_ENLIGHTENED_VMCS 163
>>  #define KVM_CAP_EXCEPTION_PAYLOAD 164
>>  #define KVM_CAP_ARM_VM_IPA_SIZE 165
>> +#define KVM_CAP_HYPERV_STIMER_DIRECT 166
>
> I wonder if all these capabilities shouldn't be replaced by a single
> KVM_GET_HYPERV_SUPPORTED_CPUID ioctl, or something like that.  If you
> can do it for 4.21, before this one cap is crystallized into userspace
> API, that would be great. :)

Oh, so the suggestion is to get all these features in CPUID format
(leafs 0x40000001-0x4000000A at this moment - as Hyper-V encodes them)
and let userspace parse them. Could work. Will take a look.

Alternatively, we can go with 'something like that' and add a
generalized KVM_GET_HYPERV_SUPPORTED_CAPS ioctl (returning somehthing
like u64 feature, u64 parameter pair). Doing that, however, wouldn't
relieve us from adding a new KVM_CAP_HYPERV_* constant for every new
feature.

-- 
Vitaly