On Thu, Jan 06, 2011 at 12:10:44AM -1000, Zachary Amsden wrote:
+static void svm_set_tsc_trapping(struct kvm_vcpu *vcpu, bool trap)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+ if (trap)
+ svm-vmcb-control.intercept |= 1ULL INTERCEPT_RDTSC;
+ else
+
On 01/07/2011 01:23 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:44AM -1000, Zachary Amsden wrote:
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
On Thu, Jan 06, 2011 at 12:10:44AM -1000, Zachary Amsden wrote:
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
Am 06.01.2011 um 11:10 schrieb Zachary Amsden zams...@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
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@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
On 01/06/2011 12:10 PM, Zachary Amsden wrote:
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
On 06.01.2011, at 12:30, Zachary Amsden wrote:
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@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
On 01/06/2011 01:32 AM, Avi Kivity wrote:
On 01/06/2011 12:10 PM, Zachary Amsden wrote:
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
On 01/06/2011 01:38 AM, Alexander Graf wrote:
On 06.01.2011, at 12:30, Zachary Amsden wrote:
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Reasons to trap the TSC are numerous, but we want to avoid it as
On 06.01.2011, at 21:24, Zachary Amsden wrote:
On 01/06/2011 01:38 AM, Alexander Graf wrote:
On 06.01.2011, at 12:30, Zachary Amsden wrote:
On 01/06/2011 12:41 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Reasons to trap
On 01/06/2011 12:38 PM, Alexander Graf wrote:
snip
Sure, I'm not saying your patch is bad or goes in the wrong direction. I'd just
think it'd be awesome to have an easy way for the guest OS to know that
something as crucial as TSC reading speed got changed, hopefully even TSC
frequency.
11 matches
Mail list logo
