Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp2298408ybg; Fri, 5 Jun 2020 10:18:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSPzd++Dagonr52B5JkqmKKXdZPYgbCoZR3Z9LPFxZornan9PKIVUcrVCcWTYqG9bPIxzV X-Received: by 2002:a05:6402:22ca:: with SMTP id dm10mr6764973edb.115.1591377512611; Fri, 05 Jun 2020 10:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591377512; cv=none; d=google.com; s=arc-20160816; b=XzJHsbe3A0AXX3AFh2xaGuD3/lEBx/9kdTt4czrQHt0TDZuXlRPfmRRY9xmrkd5vFm P1uiPnVPTc36Y+cKyq4RCkYZH4gtS4JHKi8a4EanTpmoFTzRPR+wlV6HKTyO/+upEOKS Ibuo18ane+mxNBriD5hLQHaKSiIu2uD+0ePVs1r2cRWYAlqayuww4i8tqSZfj1Wqv2oM U7yhLSoBkd+QRZrWR2wMhAWEJSiUFkWUgyXvXR7TSeLNDQE76gwPkE6PV8xqFXjykKCk KUDsf0Rsrira2J2LVkXV4HlJdS1weNjReDCySio8bTxVzDpeTYyMKvqJRXudcgn8AbbF 0HGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=M2DoiL3N8PLmn9uLhfvBWbNohAxFlys4Mkq27kcN6Kc=; b=gA0GfqQBHrVRTTeMSg/pxcaiNVCceiwY9ICRrJLPeUdn9M2kBJyuU2H0c+NsJtb46R ttNpsFWxb+/lgbr7TVVyZD/YDneZicyqwX15TsOobB5EdNOiYxaqAzLE0a0W6SFcWobE DLilstuFWCOgcC9ZNjhFrnAwGsa1VSoWj+kkYbXU1waHAD0NNQKhGJNGNd0cWmTAiJPL jCr8H2d99w2bZRTVWWU6dUWvq6eAyE7+agdt+L+1Rpu2FJeOOlIJnpBb7SLl402RaQUU gMnv96MXB7nY7tHjKIdpmjMNSKxop2OMQMhMhkiNeOQ8BDjgHco894jX0TFzMxQrjryg O2hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Okspnzrd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i17si3931510ejd.416.2020.06.05.10.18.10; Fri, 05 Jun 2020 10:18:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Okspnzrd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726983AbgFERQV (ORCPT + 99 others); Fri, 5 Jun 2020 13:16:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726026AbgFERQV (ORCPT ); Fri, 5 Jun 2020 13:16:21 -0400 Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CAC0C08C5C2 for ; Fri, 5 Jun 2020 10:16:21 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id y5so11154458iob.12 for ; Fri, 05 Jun 2020 10:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M2DoiL3N8PLmn9uLhfvBWbNohAxFlys4Mkq27kcN6Kc=; b=Okspnzrd1e2cu+pXAl0800c5udnBzbjtNe3gaWz6jgdC3P6ABXTtAXRJ+z8JGtxjsp iIGXRhiCX8dD3vHfUM75NzOZ6+MputDzUwvEJJjE48pKNB9ZQsHDEvjtJkay2dKP7+Us hvYoHtlgjrPzvwL9iHfyVlIVNa6KSHYmcbc+zgQ0MUuW7pn40iwJJlbfRFJDwJSQCYb3 d3EqhkEk4k0J45+06NODSdXREPElGKLVjlo57ocvnzl5cYe1aCI5q2b12t2MGO8vidnv qaf06RTq5zu66oYB10nc4LkspNGeS+FJxuW5ek0tD+LdZOx1UTbtpKi8EHj2l1OGErAQ LDeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M2DoiL3N8PLmn9uLhfvBWbNohAxFlys4Mkq27kcN6Kc=; b=sIgYkwzyUCV1TfLyjhvCT5uBLhzfRX9BK+cYuwpG7NFwpVaiCekXJVrIbhjBPv0slK IoU3kbEIAmvyBxScFeU6EQYeDuzDvVw6BX+TqTf78Z7boo3H2vCUL4KwcbhxqMMEQSD4 Pd2MWMoh+Ya8mWUh7bmQ2AKY9MabI913MXoHAb7bwWdHvu0IB3mEmPQUBbiLg3qOb7W9 iY+Hvw34Ybn+TqML9kzo5bDgDELXStJ4j37NKlH1KIo4cTEGY2vzwO0fCeEeX/V51LNw 5+nA8uycQhx0Lpyqy91PYCLGV69zTq/bE8qqsjszFGmG+NbE0211k1mEzSokp+ntnfxk oibA== X-Gm-Message-State: AOAM532a1WsgEI+HJ5TWJSi7F8K3FGZT2Qo4R0WPPzJJ6FG15J734539 itNDdPZHHDZdZSc5V28u4A3lkrTlxaWPdkvgWbnPuw== X-Received: by 2002:a05:6602:1647:: with SMTP id y7mr9288644iow.75.1591377379827; Fri, 05 Jun 2020 10:16:19 -0700 (PDT) MIME-Version: 1.0 References: <1591321466-2046-1-git-send-email-lirongqing@baidu.com> <72a75924-c3cb-6b23-62bd-67b739dec166@redhat.com> In-Reply-To: <72a75924-c3cb-6b23-62bd-67b739dec166@redhat.com> From: Jim Mattson Date: Fri, 5 Jun 2020 10:16:08 -0700 Message-ID: Subject: Re: [PATCH][v6] KVM: X86: support APERF/MPERF registers To: Paolo Bonzini Cc: Xiaoyao Li , Li RongQing , LKML , kvm list , "the arch/x86 maintainers" , "H . Peter Anvin" , Borislav Petkov , Ingo Molnar , Thomas Gleixner , Wanpeng Li , Vitaly Kuznetsov , Sean Christopherson , wei.huang2@amd.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 4, 2020 at 11:35 PM Paolo Bonzini wrote: > > On 05/06/20 07:00, Xiaoyao Li wrote: > > you could do > > > > bool guest_cpuid_aperfmperf = false; > > if (best) > > guest_cpuid_aperfmperf = !!(best->ecx & BIT(0)); > > > > if (guest_cpuid_aperfmerf != guest_has_aperfmperf(vcpu->kvm)) > > return -EINVAL; > > > > > > In fact, I think we can do nothing here. Leave it as what usersapce > > wants just like how KVM treats other CPUID bits. > > The reason to do it like Rongqing did is that it's suggested to take the > output of KVM_GET_SUPPORTED_CPUID and pass it down to KVM_SET_CPUID2. > Unfortunately we have KVM_GET_SUPPORTED_CPUID as a /dev/kvm (not VM) > ioctl, otherwise you could have used guest_has_aperfmperf to affect the > output of KVM_GET_SUPPORTED_CPUID. > > I think it's okay however to keep it simple as you suggest. In this > case however __do_cpuid_func must not return the X86_FEATURE_APERFMPERF bit. > > The guest can instead check for the availability of KVM_CAP_APERFMPERF, > which is already done in Rongqing's patch. > > >> @@ -4930,6 +4939,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > >> kvm->arch.exception_payload_enabled = cap->args[0]; > >> r = 0; > >> break; > >> + case KVM_CAP_APERFMPERF: > >> + kvm->arch.aperfmperf_mode = > >> + boot_cpu_has(X86_FEATURE_APERFMPERF) ? cap->args[0] : 0; > > > > Shouldn't check whether cap->args[0] is a valid value? > > Yes, only valid values should be allowed. > > Also, it should fail with -EINVAL if the host does not have > X86_FEATURE_APERFMPERF. Should enabling/disabling this capability be disallowed once vCPUs have been created?