From: Zachary Amsden <zamsden@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [KVM TSC trapping / migration 1/2] Add TSC trapping for SVM and VMX
Date: Thu, 06 Jan 2011 01:30:43 -1000 [thread overview]
Message-ID: <4D25A7E3.4090101@redhat.com> (raw)
In-Reply-To: <9EEA19E7-668A-4CD0-B006-6B494D9FD242@suse.de>
On 01/06/2011 12:41 AM, Alexander Graf wrote:
> Am 06.01.2011 um 11:10 schrieb Zachary Amsden<zamsden@redhat.com>:
>
>
>> Reasons to trap the TSC are numerous, but we want to avoid it as much
>> as possible for performance reasons.
>>
>> We provide two conservative modes via modules parameters and userspace
>> hinting. First, the module can be loaded with "tsc_auto=1" as a module
>> parameter, which turns on conservative TSC trapping only when it is
>> required (when unstable TSC or faster KHZ CPU is detected).
>>
>> For userspace hinting, we enable trapping only if necessary. Userspace
>> can hint that a VM needs a fixed frequency TSC, and also that SMP
>> stability will be required. In that case, we conservatively turn on
>> trapping when it is needed. In addition, users may now specify the
>> desired TSC rate at which to run. If this rate differs significantly
>> from the host rate, trapping will be enabled.
>>
>> There is also an override control to allow TSC trapping to be turned on
>> or off unconditionally for testing.
>>
>> We indicate to pvclock users that the TSC is being trapped, to allow
>> avoiding overhead and directly using RDTSCP (only for SVM). This
>> optimization is not yet implemented.
>>
> When migrating, the implementation could switch from non-trapped to trapped, making it less attractive. The guest however does not get notified about this change. Same for the other way around.
>
That's a policy decision to be made by the userspace agent. It's better
than the current situation, where there is no control at all of TSC
rate. Here, we're flexible either way.
Also note, moving to a faster processor, trapping kicks in... but the
processor is faster, so no actual loss is noticed, and the problem
corrects when the VM is power cycled.
> Would it make sense to add a kvmclock interrupt to notify the guest of such a change?
kvmclock is immune to frequency changes, so it needs no interrupt, it
just has a version controlled shared area, which is reset.
next prev parent reply other threads:[~2011-01-06 11:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 10:10 KVM TSC trapping Zachary Amsden
2011-01-06 10:10 ` [KVM TSC trapping / migration 1/2] Add TSC trapping for SVM and VMX Zachary Amsden
2011-01-06 10:41 ` Alexander Graf
2011-01-06 11:30 ` Zachary Amsden [this message]
2011-01-06 11:38 ` Alexander Graf
2011-01-06 20:24 ` Zachary Amsden
2011-01-06 22:38 ` Alexander Graf
2011-01-07 3:10 ` Zachary Amsden
2011-01-06 11:32 ` Avi Kivity
2011-01-06 20:03 ` Zachary Amsden
2011-01-07 11:23 ` Marcelo Tosatti
2011-01-09 8:05 ` Zachary Amsden
2011-01-10 11:52 ` Joerg Roedel
2011-01-06 10:10 ` Zachary Amsden
2011-01-06 10:10 ` [KVM TSC trapping / migration 2/2] Add TSC KHZ MSR Zachary Amsden
2011-01-06 10:34 ` Alexander Graf
2011-01-06 11:27 ` Zachary Amsden
2011-01-06 11:40 ` Alexander Graf
2011-01-06 20:34 ` Zachary Amsden
2011-01-07 10:48 ` Marcelo Tosatti
2011-01-07 20:44 ` Zachary Amsden
2011-01-10 13:50 ` Marcelo Tosatti
2011-01-14 11:00 ` Juan Quintela
2011-01-18 15:47 ` Zachary Amsden
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=4D25A7E3.4090101@redhat.com \
--to=zamsden@redhat.com \
--cc=agraf@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.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