From: David Hildenbrand <david@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Liran Alon <liran.alon@oracle.com>,
rkrcmar@redhat.com, kvm@vger.kernel.org
Cc: idan.brown@oracle.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] KVM: x86: Add emulation of MSR_SMI_COUNT
Date: Mon, 4 Dec 2017 10:32:40 +0100 [thread overview]
Message-ID: <96644ab8-4663-5cab-8ccd-acec82019dec@redhat.com> (raw)
In-Reply-To: <79e109dd-96d6-c4e1-6441-2673a1b8dbff@redhat.com>
On 04.12.2017 10:31, Paolo Bonzini wrote:
> On 04/12/2017 10:27, David Hildenbrand wrote:
>> On 15.11.2017 12:43, Liran Alon wrote:
>>> This MSR returns the number of #SMIs that occurred on CPU since
>>> boot.
>>>
>>> It was seen to be used frequently by ESXi guest.
>>>
>>> Patch adds a new vcpu-arch specific var called smi_count to
>>> save the number of #SMIs which occurred on CPU since boot.
>>> It is exposed as a read-only MSR to guest (causing #GP
>>> on wrmsr) in RDMSR/WRMSR emulation code.
>>> MSR_SMI_COUNT is also added to emulated_msrs[] to make sure
>>> user-space can save/restore it for migration purposes.
>>>
>>> Signed-off-by: Liran Alon <liran.alon@oracle.com>
>>> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
>>> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
>>> Reviewed-by: Bhavesh Davda <bhavesh.davda@oracle.com>
>>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>
>>> Notes:
>>> To make vmsave/vload work for MSR_SMI_COUNT (for migration purposes),
>>> a patch for QEMU is also required.
>>> We have written such patch and verified that it works.
>>> It will be submitted seperately to the QEMU mailing list.
>>>
>>> arch/x86/include/asm/kvm_host.h | 1 +
>>> arch/x86/kvm/x86.c | 11 +++++++++++
>>> 2 files changed, 12 insertions(+)
>>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>>> index c73e493adf07..089856eeac5d 100644
>>> --- a/arch/x86/include/asm/kvm_host.h
>>> +++ b/arch/x86/include/asm/kvm_host.h
>>> @@ -504,6 +504,7 @@ struct kvm_vcpu_arch {
>>> int mp_state;
>>> u64 ia32_misc_enable_msr;
>>> u64 smbase;
>>> + u64 smi_count;
>>> bool tpr_access_reporting;
>>> u64 ia32_xss;
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 21c00594f230..dedf5539f924 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -1036,6 +1036,7 @@ bool kvm_rdpmc(struct kvm_vcpu *vcpu)
>>> MSR_IA32_MCG_CTL,
>>> MSR_IA32_MCG_EXT_CTL,
>>> MSR_IA32_SMBASE,
>>> + MSR_SMI_COUNT,
>>> MSR_PLATFORM_INFO,
>>> MSR_MISC_FEATURES_ENABLES,
>>> };
>>> @@ -2217,6 +2218,11 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>>> return 1;
>>> vcpu->arch.smbase = data;
>>> break;
>>> + case MSR_SMI_COUNT:
>>> + if (!msr_info->host_initiated)
>>> + return 1;
>>> + vcpu->arch.smi_count = data;
>>> + break;
>>> case MSR_KVM_WALL_CLOCK_NEW:
>>> case MSR_KVM_WALL_CLOCK:
>>> vcpu->kvm->arch.wall_clock = data;
>>> @@ -2491,6 +2497,9 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>>> return 1;
>>> msr_info->data = vcpu->arch.smbase;
>>> break;
>>> + case MSR_SMI_COUNT:
>>> + msr_info->data = vcpu->arch.smi_count;
>>> + break;
>>> case MSR_IA32_PERF_STATUS:
>>> /* TSC increment by tick */
>>> msr_info->data = 1000ULL;
>>> @@ -6437,6 +6446,7 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win)
>>> kvm_x86_ops->queue_exception(vcpu);
>>> } else if (vcpu->arch.smi_pending && !is_smm(vcpu)) {
>>> vcpu->arch.smi_pending = false;
>>> + ++vcpu->arch.smi_count;
>>> enter_smm(vcpu);
>>> } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) {
>>> --vcpu->arch.nmi_pending;
>>> @@ -7781,6 +7791,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
>>> vcpu->arch.hflags = 0;
>>>
>>> vcpu->arch.smi_pending = 0;
>>> + vcpu->arch.smi_count = 0;
>>> atomic_set(&vcpu->arch.nmi_queued, 0);
>>> vcpu->arch.nmi_pending = 0;
>>> vcpu->arch.nmi_injected = false;
>>>
>>
>> Reviewed-by: David Hildenbrand <david@redhat.com>
>>
>> (only wondering if we have to make availability depend on e.g. a
>> KVM_CAP, so a guest will not silently start using it, although migration
>> with old QEMUs is broken)
>
> No need for a capability, old QEMU will just reset to 0 on migration.
>
If that is acceptable (i.e. smi_count might jump back) , fine with me.
> Paolo
>
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2017-12-04 9:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 11:43 [PATCH] KVM: x86: Add emulation of MSR_SMI_COUNT Liran Alon
2017-11-15 13:47 ` Paolo Bonzini
2017-12-04 9:27 ` David Hildenbrand
2017-12-04 9:31 ` Paolo Bonzini
2017-12-04 9:32 ` David Hildenbrand [this message]
2017-12-05 21:09 ` Radim Krčmář
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=96644ab8-4663-5cab-8ccd-acec82019dec@redhat.com \
--to=david@redhat.com \
--cc=idan.brown@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/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