From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Li RongQing <lirongqing@baidu.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
x86@kernel.org, hpa@zytor.com, bp@alien8.de, mingo@redhat.com,
tglx@linutronix.de, jmattson@google.com, wanpengli@tencent.com,
vkuznets@redhat.com, sean.j.christopherson@intel.com,
pbonzini@redhat.com, wei.huang2@amd.com
Subject: Re: [PATCH][v6] KVM: X86: support APERF/MPERF registers
Date: Fri, 5 Jun 2020 13:00:53 +0800 [thread overview]
Message-ID: <b70d03dd-947f-dee5-5499-3b381372497d@intel.com> (raw)
In-Reply-To: <1591321466-2046-1-git-send-email-lirongqing@baidu.com>
On 6/5/2020 9:44 AM, Li RongQing wrote:
> Guest kernel reports a fixed cpu frequency in /proc/cpuinfo,
> this is confused to user when turbo is enable, and aperf/mperf
> can be used to show current cpu frequency after 7d5905dc14a
> "(x86 / CPU: Always show current CPU frequency in /proc/cpuinfo)"
> so guest should support aperf/mperf capability
>
> This patch implements aperf/mperf by three mode: none, software
> emulation, and pass-through
>
> None: default mode, guest does not support aperf/mperf
>
> Software emulation: the period of aperf/mperf in guest mode are
> accumulated as emulated value
>
> Pass-though: it is only suitable for KVM_HINTS_REALTIME, Because
> that hint guarantees we have a 1:1 vCPU:CPU binding and guaranteed
> no over-commit.
>
> And a per-VM capability is added to configure aperfmperf mode
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Signed-off-by: Chai Wen <chaiwen@baidu.com>
> Signed-off-by: Jia Lina <jialina01@baidu.com>
> ---
> diff v5:
> return error if guest is configured with mperf/aperf, but host cpu has not
>
> diff v4:
> fix maybe-uninitialized warning
>
> diff v3:
> fix interception of MSR_IA32_MPERF/APERF in svm
>
> diff v2:
> support aperfmperf pass though
> move common codes to kvm_get_msr_common
>
> diff v1:
> 1. support AMD, but not test
> 2. support per-vm capability to enable
>
>
> Documentation/virt/kvm/api.rst | 10 ++++++++++
> arch/x86/include/asm/kvm_host.h | 11 +++++++++++
> arch/x86/kvm/cpuid.c | 15 ++++++++++++++-
> arch/x86/kvm/svm/svm.c | 8 ++++++++
> arch/x86/kvm/vmx/vmx.c | 6 ++++++
> arch/x86/kvm/x86.c | 42 +++++++++++++++++++++++++++++++++++++++++
> arch/x86/kvm/x86.h | 15 +++++++++++++++
> include/uapi/linux/kvm.h | 1 +
> 8 files changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index d871dacb984e..f854f4da6fd8 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6126,3 +6126,13 @@ KVM can therefore start protected VMs.
> This capability governs the KVM_S390_PV_COMMAND ioctl and the
> KVM_MP_STATE_LOAD MP_STATE. KVM_SET_MP_STATE can fail for protected
> guests when the state change is invalid.
> +
> +8.23 KVM_CAP_APERFMPERF
> +----------------------------
> +
> +:Architectures: x86
> +:Parameters: args[0] is aperfmperf mode;
> + 0 for not support, 1 for software emulation, 2 for pass-through
> +:Returns: 0 on success; -1 on error
> +
> +This capability indicates that KVM supports APERF and MPERF MSR registers
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index fd78bd44b2d6..14643f8af9c4 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -824,6 +824,9 @@ struct kvm_vcpu_arch {
>
> /* AMD MSRC001_0015 Hardware Configuration */
> u64 msr_hwcr;
> +
> + u64 v_mperf;
> + u64 v_aperf;
> };
>
> struct kvm_lpage_info {
> @@ -889,6 +892,12 @@ enum kvm_irqchip_mode {
> KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */
> };
>
> +enum kvm_aperfmperf_mode {
> + KVM_APERFMPERF_NONE,
> + KVM_APERFMPERF_SOFT, /* software emulate aperfmperf */
> + KVM_APERFMPERF_PT, /* pass-through aperfmperf to guest */
> +};
> +
> #define APICV_INHIBIT_REASON_DISABLE 0
> #define APICV_INHIBIT_REASON_HYPERV 1
> #define APICV_INHIBIT_REASON_NESTED 2
> @@ -986,6 +995,8 @@ struct kvm_arch {
>
> struct kvm_pmu_event_filter *pmu_event_filter;
> struct task_struct *nx_lpage_recovery_thread;
> +
> + enum kvm_aperfmperf_mode aperfmperf_mode;
> };
>
> struct kvm_vm_stat {
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index cd708b0b460a..80f18b29a845 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -122,6 +122,16 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
> MSR_IA32_MISC_ENABLE_MWAIT);
> }
>
> + best = kvm_find_cpuid_entry(vcpu, 6, 0);
> + if (best) {
> + if (guest_has_aperfmperf(vcpu->kvm)) {
> + if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
> + return -EINVAL;
kvm_vm_ioctl_enable_cap() ensures that guest_has_aperfmperf() always
aligns with boot_cpu_has(X86_FEATURE_APERFMPERF). So above is unnecessary.
> + best->ecx |= 1;
> + } else {
> + best->ecx &= ~1;
> + }
> + }
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.
Paolo,
What's your point?
> /* Note, maxphyaddr must be updated before tdp_level. */
> vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
> vcpu->arch.tdp_level = kvm_x86_ops.get_tdp_level(vcpu);
[...]
> @@ -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?
> + r = 0;
> + break;
> default:
> r = -EINVAL;
> break;
next prev parent reply other threads:[~2020-06-05 5:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 1:44 [PATCH][v6] KVM: X86: support APERF/MPERF registers Li RongQing
2020-06-05 2:32 ` Xu, Like
2020-06-05 4:23 ` 答复: " Li,Rongqing
2020-06-05 5:28 ` Like Xu
2020-06-05 9:41 ` 答复: " Li,Rongqing
2020-06-05 11:15 ` Paolo Bonzini
2020-06-05 5:00 ` Xiaoyao Li [this message]
2020-06-05 6:35 ` Paolo Bonzini
2020-06-05 17:16 ` Jim Mattson
2020-06-05 17:22 ` Paolo Bonzini
2020-06-06 11:53 ` 答复: " Li,Rongqing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b70d03dd-947f-dee5-5499-3b381372497d@intel.com \
--to=xiaoyao.li@intel.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=wei.huang2@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox