On Wed, Oct 19, 2016 at 05:42:16PM +0200, Radim Krčmář wrote:
> 2016-10-19 11:55-0200, Eduardo Habkost:
> > On Wed, Oct 19, 2016 at 03:27:52PM +0200, Radim Krčmář wrote:
> >> 2016-10-18 19:05-0200, Eduardo Habkost:
> >> > On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
> >> > [...]
>
2016-10-19 11:55-0200, Eduardo Habkost:
> On Wed, Oct 19, 2016 at 03:27:52PM +0200, Radim Krčmář wrote:
>> 2016-10-18 19:05-0200, Eduardo Habkost:
>> > On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
>> > [...]
>> >> The main problem is that QEMU changes virtual_tsc_khz when migrating
On Wed, Oct 19, 2016 at 03:27:52PM +0200, Radim Krčmář wrote:
> 2016-10-18 19:05-0200, Eduardo Habkost:
> > On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
> > [...]
> >> The main problem is that QEMU changes virtual_tsc_khz when migrating
> >> without hardware scaling, so KVM is forc
2016-10-18 19:05-0200, Eduardo Habkost:
> On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
> [...]
>> The main problem is that QEMU changes virtual_tsc_khz when migrating
>> without hardware scaling, so KVM is forced to get nanoseconds wrong ...
>>
>> If QEMU doesn't want to keep the
On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
[...]
> The main problem is that QEMU changes virtual_tsc_khz when migrating
> without hardware scaling, so KVM is forced to get nanoseconds wrong ...
>
> If QEMU doesn't want to keep the TSC frequency constant, then it would
> be bette
2016-10-18 15:09-0200, Marcelo Tosatti:
> On Tue, Oct 18, 2016 at 03:41:03PM +0200, Paolo Bonzini wrote:
>> On 18/10/2016 01:58, Marcelo Tosatti wrote:
>> > > We should also blacklist the TSC deadline timer when invtsc is not
>> > > available.
>> >
>> > Actually, a nicer fix would be to check the d
On Tue, Oct 18, 2016 at 03:41:03PM +0200, Paolo Bonzini wrote:
>
>
> On 18/10/2016 01:58, Marcelo Tosatti wrote:
> > > We should also blacklist the TSC deadline timer when invtsc is not
> > > available.
> >
> > Actually, a nicer fix would be to check the different
> > frequencies and scale the d
2016-10-17 21:58-0200, Marcelo Tosatti:
> On Mon, Oct 17, 2016 at 07:11:01PM -0200, Eduardo Habkost wrote:
>> On Mon, Oct 17, 2016 at 06:24:38PM +0200, Paolo Bonzini wrote:
>> > On 17/10/2016 16:50, Radim Krčmář wrote:
>> > > 2016-10-17 07:47-0200, Marcelo Tosatti:
>> [...]
>> > >> since Linux gues
On 18/10/2016 01:58, Marcelo Tosatti wrote:
> > We should also blacklist the TSC deadline timer when invtsc is not
> > available.
>
> Actually, a nicer fix would be to check the different
> frequencies and scale the deadline relative to the difference.
You cannot know what exactly the guest wa
2016-10-17 18:24+0200, Paolo Bonzini:
> On 17/10/2016 16:50, Radim Krčmář wrote:
>> 2016-10-17 07:47-0200, Marcelo Tosatti:
>>> On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
I have been wondering: should we allow live migration with the
invtsc flag enabled, if TSC scali
2016-10-18 15:36+0200, Radim Krčmář:
> 2016-10-17 18:24+0200, Paolo Bonzini:
>> We should also blacklist the TSC deadline timer when invtsc is not
>> available.
>
> True.
>
> I was thinking that with Wanpeng's VMX preemption patches, we might not
> need the TSC nor paravirtual deadline timer, the
2016-10-17 15:20-0200, Marcelo Tosatti:
> On Mon, Oct 17, 2016 at 04:50:09PM +0200, Radim Krčmář wrote:
>> 2016-10-17 07:47-0200, Marcelo Tosatti:
>> > On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
>> >> I have been wondering: should we allow live migration with the
>> >> invtsc
* Radim Krčmář (rkrc...@redhat.com) wrote:
> 2016-10-17 07:47-0200, Marcelo Tosatti:
> > On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
> >> I have been wondering: should we allow live migration with the
> >> invtsc flag enabled, if TSC scaling is available on the
> >> destination
On Mon, Oct 17, 2016 at 07:11:01PM -0200, Eduardo Habkost wrote:
> On Mon, Oct 17, 2016 at 06:24:38PM +0200, Paolo Bonzini wrote:
> > On 17/10/2016 16:50, Radim Krčmář wrote:
> > > 2016-10-17 07:47-0200, Marcelo Tosatti:
> [...]
> > >> since Linux guests use kvmclock and Windows guests use Hyper-V
On Mon, Oct 17, 2016 at 06:24:38PM +0200, Paolo Bonzini wrote:
> On 17/10/2016 16:50, Radim Krčmář wrote:
> > 2016-10-17 07:47-0200, Marcelo Tosatti:
[...]
> >> since Linux guests use kvmclock and Windows guests use Hyper-V
> >> enlightenment, it should be fine to disable 2).
>
> ... and 1 too.
>
On Mon, Oct 17, 2016 at 04:50:09PM +0200, Radim Krčmář wrote:
> 2016-10-17 07:47-0200, Marcelo Tosatti:
> > On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
> >> I have been wondering: should we allow live migration with the
> >> invtsc flag enabled, if TSC scaling is available on t
On 17/10/2016 16:50, Radim Krčmář wrote:
> 2016-10-17 07:47-0200, Marcelo Tosatti:
>> On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
>>> I have been wondering: should we allow live migration with the
>>> invtsc flag enabled, if TSC scaling is available on the
>>> destination?
>>
2016-10-17 07:47-0200, Marcelo Tosatti:
> On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
>> I have been wondering: should we allow live migration with the
>> invtsc flag enabled, if TSC scaling is available on the
>> destination?
>
> TSC scaling and invtsc flag, yes.
Yes, if we
On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
> I have been wondering: should we allow live migration with the
> invtsc flag enabled, if TSC scaling is available on the
> destination?
TSC scaling and invtsc flag, yes.
>
> For reference, this is what the Intel SDM says about in
I have been wondering: should we allow live migration with the
invtsc flag enabled, if TSC scaling is available on the
destination?
For reference, this is what the Intel SDM says about invtsc:
The time stamp counter in newer processors may support an
enhancement, referred to as invariant TSC.
20 matches
Mail list logo
