..@hotmail.com>
>> wrote:
>> > Hi Guys,
>> >
>> > I found below patch for KVM TSC trapping / migration support,
>> >
>> > https://lkml.org/lkml/2011/1/6/90
>> >
>> > It seemed the patch were not merged in Linux mainline.
&
David,
Sorry for late reply. See my inline comments.
On Tue, 15 Sep 2015, David Matlack wrote:
> On Tue, Sep 15, 2015 at 12:04 AM, Oliver Yang <yang_oli...@hotmail.com> wrote:
> > Hi Guys,
> >
> > I found below patch for KVM TSC trapping / migration support,
> &g
On 9/16/15 6:00 AM, David Matlack wrote:
On Tue, Sep 15, 2015 at 12:04 AM, Oliver Yang <yang_oli...@hotmail.com> wrote:
Hi Guys,
I found below patch for KVM TSC trapping / migration support,
https://lkml.org/lkml/2011/1/6/90
It seemed the patch were not merged in Linux mainline.
So I
On Tue, Sep 15, 2015 at 12:04 AM, Oliver Yang <yang_oli...@hotmail.com> wrote:
> Hi Guys,
>
> I found below patch for KVM TSC trapping / migration support,
>
> https://lkml.org/lkml/2011/1/6/90
>
> It seemed the patch were not merged in Linux mainline.
>
> So I h
Hi Guys,
I found below patch for KVM TSC trapping / migration support,
https://lkml.org/lkml/2011/1/6/90
It seemed the patch were not merged in Linux mainline.
So I have 3 questions here,
1. Can KVM support TSC trapping today? If not, what is the plan?
2. What is the solution if my SMP
On 01/14/2011 06:00 AM, Juan Quintela wrote:
Marcelo Tosattimtosa...@redhat.com wrote:
On Fri, Jan 07, 2011 at 10:44:20AM -1000, Zachary Amsden wrote:
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
Marcelo Tosatti mtosa...@redhat.com wrote:
On Fri, Jan 07, 2011 at 10:44:20AM -1000, Zachary Amsden wrote:
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
Use an MSR to allow soft migration to hosts which do not support
TSC
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 Fri, Jan 07, 2011 at 10:44:20AM -1000, Zachary Amsden wrote:
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required
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:45AM -1000, Zachary Amsden wrote:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be exported as a data
field (useful in its own right),
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
On 01/07/2011 12:48 AM, Marcelo Tosatti wrote:
On Thu, Jan 06, 2011 at 12:10:45AM -1000, Zachary Amsden wrote:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be
On top of my last patchset, I now implement TSC trapping and
a flexible migration scheme for maintaining stable TSC across
migration. Since it is administratively configured, it can
be selectively enabled only for VMs which require it. In
particular, VMs which use KVM clock probably do not want
Am 06.01.2011 um 11:10 schrieb Zachary Amsden zams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be exported as a data
field (useful in its own
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:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
migration protocol, we allow the TSC rate to be
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 06.01.2011, at 12:27, Zachary Amsden wrote:
On 01/06/2011 12:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC trapping. Rather than make this a required element of any
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 01/06/2011 01:40 AM, Alexander Graf wrote:
On 06.01.2011, at 12:27, Zachary Amsden wrote:
On 01/06/2011 12:34 AM, Alexander Graf wrote:
Am 06.01.2011 um 11:10 schrieb Zachary Amsdenzams...@redhat.com:
Use an MSR to allow soft migration to hosts which do not support
TSC
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.
26 matches
Mail list logo
