Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp880762imu; Wed, 28 Nov 2018 00:44:39 -0800 (PST) X-Google-Smtp-Source: AJdET5esLRCd+e2Xwn+mJZ+VxdW6OizeYgyxatnwRXI4+Kpw5LEXDLxY8eZgmMXaWs8BHW6ZfhXi X-Received: by 2002:a62:5dd1:: with SMTP id n78mr35999583pfj.58.1543394679542; Wed, 28 Nov 2018 00:44:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543394679; cv=none; d=google.com; s=arc-20160816; b=pQ7BRwKN04uF/dYyVczwRRS424/ZM+PbAGcRw+sDRiNkuj0XNUTDLCZiv2vMoxsW5x e6E+rVKmShyW67B6Rmzvt/pQJ70VQPRPWIYHQy7neF1J+/dT+45dlcUyc1+JDc9qZqYF QJaDhLoE5G7UC1uhaE6IZihxZIsy8YHeAV9x7I5pC+1VVVkx97yUC4ozkWWVkBsh5CbD 7ZWV2+IxG7D/CMby9tzABv2f0K/XpVkdFgzR6bNo7A1CyKhpaoZuwcpo9r11RxwJiqjD MPCWe3lNiVMcHTlmU7h4TGxfuT7BamKOMuv+ZQsyWmfpfitFvm1z7DgIb75W6obDrPNd Q9CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:to:subject; bh=pzh7KWf4Rf3n6dMBqLSc98jfRmo/eaXVqR7ZCVc0IOQ=; b=G0GarW7vzxw0l59Munwu89V1qC0xVb+b7ukIYXPK9JOreqwkYPvwYvR45jV/2ZfrTh 1V7SQtPwuIsfmP+WgCxYoSk+QUmCgwVTY9lr5tjRCUCOHGFufpnRR+DLHGgScgeqiGIn guRfVZF2jEVS/JEjjt4uAqSXWUafBsULwiiVa+EgWKK8OUxFEHhEJpKv6PWi03GmpOM4 w6KuC5L4wFsMAxyUzYYR768Aji9MuTrSx1gsRaZJCjAV100MgfrmVarLHrFs2bXvVK+n +dPH6phN4d1Ab2dN5aDfkieRjHbCuU11vW/dgz/hsYgqJWmA5O7BhYBf4EPefQ3lSpk0 0tkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b11si6132909pgb.536.2018.11.28.00.44.24; Wed, 28 Nov 2018 00:44:39 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727885AbeK1Toc (ORCPT + 99 others); Wed, 28 Nov 2018 14:44:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55124 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727519AbeK1Toc (ORCPT ); Wed, 28 Nov 2018 14:44:32 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EC70230820F2; Wed, 28 Nov 2018 08:43:41 +0000 (UTC) Received: from [10.36.112.58] (ovpn-112-58.ams2.redhat.com [10.36.112.58]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2AEB6BF73; Wed, 28 Nov 2018 08:43:36 +0000 (UTC) Subject: Re: [PATCH v2 3/4] x86/kvm/hyper-v: direct mode for synthetic timers To: Roman Kagan , Paolo Bonzini , Vitaly Kuznetsov , kvm@vger.kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , linux-kernel@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , x86@kernel.org, "Michael Kelley (EOSG)" References: <20181126154732.23025-1-vkuznets@redhat.com> <20181126154732.23025-4-vkuznets@redhat.com> <20181127083706.GB16047@rkaganb.sw.ru> <9d0e9796-b71e-9437-8cd4-a898fd503871@redhat.com> <20181127190506.GB5147@rkaganip.lan> From: Paolo Bonzini Openpgp: preference=signencrypt Autocrypt: addr=pbonzini@redhat.com; prefer-encrypt=mutual; keydata= xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0f UGFvbG8gQm9uemluaSA8Ym9uemluaUBnbnUub3JnPsLBTQQTAQIAIwUCVEJ7AwIbAwcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEH4VEAzNNmmxNcwOniaZVLsuy1lW/ntYCA0Caz0i sHpmecK8aWlvL9wpQCk4GlOX9L1emyYXZPmzIYB0IRqmSzAlZxi+A2qm9XOxs5gJ2xqMEXX5 FMtUH3kpkWWJeLqe7z0EoQdUI4EG988uv/tdZyqjUn2XJE+K01x7r3MkUSFz/HZKZiCvYuze VlS0NTYdUt5jBXualvAwNKfxEkrxeHjxgdFHjYWhjflahY7TNRmuqPM/Lx7wAuyoDjlYNE40 Z+Kun4/KjMbjgpcF4Nf3PJQR8qXI6p3so2qsSn91tY7DFSJO6v2HwFJkC2jU95wxfNmTEUZc znXahYbVOwCDJRuPrE5GKFd/XJU9u5hNtr/uYipHij01WXal2cce1S5mn1/HuM1yo1u8xdHy IupCd57EWI948e8BlhpujUCU2tzOb2iYS0kpmJ9/oLVZrOcSZCcCl2P0AaCAsj59z2kwQS9D du0WxUs8waso0Qq6tDEHo8yLCOJDzSz4oojTtWe4zsulVnWV+wu70AioemAT8S6JOtlu60C5 dHgQUD1Tp+ReXpDKXmjbASJx4otvW0qah3o6JaqO79tbDqIvncu3tewwp6c85uZd48JnIOh3 utBAu684nJakbbvZUGikJfxd887ATQRUQnHuAQgAx4dxXO6/Zun0eVYOnr5GRl76+2UrAAem Vv9Yfn2PbDIbxXqLff7oyVJIkw4WdhQIIvvtu5zH24iYjmdfbg8iWpP7NqxUQRUZJEWbx2CR wkMHtOmzQiQ2tSLjKh/cHeyFH68xjeLcinR7jXMrHQK+UCEw6jqi1oeZzGvfmxarUmS0uRuf fAb589AJW50kkQK9VD/9QC2FJISSUDnRC0PawGSZDXhmvITJMdD4TjYrePYhSY4uuIV02v02 8TVAaYbIhxvDY0hUQE4r8ZbGRLn52bEzaIPgl1p/adKfeOUeMReg/CkyzQpmyB1TSk8lDMxQ zCYHXAzwnGi8WU9iuE1P0wARAQABwsEzBBgBAgAJBQJUQnHuAhsMAAoJEH4VEAzNNmmxp1EO oJy0uZggJm7gZKeJ7iUpeX4eqUtqelUw6gU2daz2hE/jsxsTbC/w5piHmk1H1VWDKEM4bQBT uiJ0bfo55SWsUNN+c9hhIX+Y8LEe22izK3w7mRpvGcg+/ZRG4DEMHLP6JVsv5GMpoYwYOmHn plOzCXHvmdlW0i6SrMsBDl9rw4AtIa6bRwWLim1lQ6EM3PWifPrWSUPrPcw4OLSwFk0CPqC4 HYv/7ZnASVkR5EERFF3+6iaaVi5OgBd81F1TCvCX2BEyIDRZLJNvX3TOd5FEN+lIrl26xecz 876SvcOb5SL5SKg9/rCBufdPSjojkGFWGziHiFaYhbuI2E+NfWLJtd+ZvWAAV+O0d8vFFSvr iy9enJ8kxJwhC0ECbSKFY+W1eTIhMD3aeAKY90drozWEyHhENf4l/V+Ja5vOnW+gCDQkGt2Y 1lJAPPSIqZKvHzGShdh8DduC0U3xYkfbGAUvbxeepjgzp0uEnBXfPTy09JGpgWbg0w91GyfT /ujKaGd4vxG2Ei+MMNDmS1SMx7wu0evvQ5kT9NPzyq8R2GIhVSiAd2jioGuTjX6AZCFv3ToO 53DliFMkVTecLptsXaesuUHgL9dKIfvpm+rNXRn9wAwGjk0X/A== Message-ID: <9fb3bbf4-f921-ba1e-399f-4769fe774f3e@redhat.com> Date: Wed, 28 Nov 2018 09:43:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181127190506.GB5147@rkaganip.lan> Content-Type: text/plain; charset=iso-8859-2 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Wed, 28 Nov 2018 08:43:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/11/18 20:05, Roman Kagan wrote: >>> Capabilities are a well-established and unambiguous negotiation >>> mechanism, why invent another one? Besides, not all features map >>> conveniently onto cpuid bits, e.g. currently we have two versions of >>> SynIC support, which differ in the way the userspace deals with it, but >>> not in the cpuid bits we expose in the guest. IMO such an ioctl would >>> bring more complexity rather than less. >> >> Yes, in that case (for bugfixes basically) you'd have to use >> capabilities. But if the feature is completely hidden to userspace >> except for the CPUID bit, it seems like a ioctl would be more consistent >> with the rest of the KVM API. > > So there will be some features that are more equal than others? Well, it's already like that. Some features have to be explicitly KVM_ENABLE_CAP'd because userspace has to be aware of them. But in many cases they can be enabled blindly, and in that case a CPUID-based API can help. The CPUID-based API already works well for processor features, MSRs, KVM paravirt features, etc. Unfortunately we cannot just reuse KVM_GET_SUPPORTED_CPUID because userspace expects KVM features to be at 0x40000000 rather than Hyper-V ones. > I think that it's the current scheme which is more consistent: there are > features that are implemented in KVM, and there are caps for negotiating > them with userspace, and then -- separately -- there's a mix of bits to > show to the guest in response to CPUID, which only the userspace has to > bother with. The only issue is how to present the "features that are implemented in KVM". Since they _are_ expressed as CPUID bits, it makes sense if userspace only has to know about those instead of having both capabilities and CPUID bits. Paolo