From: Xiaoyao Li <xiaoyao.li@intel.com>
To: "Li,Rongqing" <lirongqing@baidu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>, "bp@alien8.de" <bp@alien8.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"jmattson@google.com" <jmattson@google.com>,
"wanpengli@tencent.com" <wanpengli@tencent.com>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"sean.j.christopherson@intel.com"
<sean.j.christopherson@intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"wei.huang2@amd.com" <wei.huang2@amd.com>
Subject: Re: 答复: [PATCH][v5] KVM: X86: support APERF/MPERF registers
Date: Sun, 31 May 2020 10:35:07 +0800 [thread overview]
Message-ID: <9c870a06-ee46-5c9d-11c0-602aeb18c83d@intel.com> (raw)
In-Reply-To: <e7ccee7dc30e4d1e8dcb8a002d6a6ed2@baidu.com>
On 5/31/2020 10:08 AM, Li,Rongqing wrote:
>
>
>> -----邮件原件-----
>> 发件人: Xiaoyao Li [mailto:xiaoyao.li@intel.com]
>> 发送时间: 2020年5月30日 18:40
>> 收件人: 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
>> 主题: Re: [PATCH][v5] KVM: X86: support APERF/MPERF registers
>>
>> On 5/30/2020 12:35 PM, 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
>>>
>>
>> [...]
>>
>>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index
>>> cd708b0b460a..c960dda4251b 100644
>>> --- a/arch/x86/kvm/cpuid.c
>>> +++ b/arch/x86/kvm/cpuid.c
>>> @@ -122,6 +122,14 @@ 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) &&
>>> + boot_cpu_has(X86_FEATURE_APERFMPERF))
>>> + best->ecx |= 1;
>>> + else
>>> + best->ecx &= ~1;
>>> + }
>>
>> In my understanding, KVM allows userspace to set a CPUID feature bit for
>> guest even if hardware doesn't support the feature.
>>
>> So what makes X86_FEATURE_APERFMPERF different here? Is there any
>> concern I miss?
>>
>> -Xiaoyao
>
> Whether software emulation for aperf/mperf or pass-through depends on host cpu aperf/mperf feature.
>
> Software emulation: the period of aperf/mperf in guest mode are accumulated as emulated value
>
I know it that you want to ensure the correctness of exposure of
aperf/mperf.
But there are so many features other than aperf/mperf that KVM reports
the supported settings of them through KVM_GET_SUPPORTED_CPUID, but
doesn't check nor force the correctness of userspace input. i.e., KVM
allows userspace to set bogus CPUID settings as long as it doesn't break
KVM (host kernel).
Indeed, bogus CPUID settings more than likely breaks the guest. But it's
not KVM's fault. KVM just do what userspace wants.
IMO, If we really want to ensure the correctness of userspace provided
CPUID settings, we need to return ERROR to userspace instead of fixing
it siliently.
- Xiaoyao
next prev parent reply other threads:[~2020-05-31 2:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-30 4:35 [PATCH][v5] KVM: X86: support APERF/MPERF registers Li RongQing
2020-05-30 10:40 ` Xiaoyao Li
2020-05-31 2:08 ` 答复: " Li,Rongqing
2020-05-31 2:35 ` Xiaoyao Li [this message]
2020-06-04 6:09 ` 答复: " 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=9c870a06-ee46-5c9d-11c0-602aeb18c83d@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;
as well as URLs for NNTP newsgroup(s).