Re: TSC deadline timer in guests vs. migration?

[Paolo Bonzini <pbonzini@redhat.com>]

On 05/07/2016 22:39, Marcelo Tosatti wrote:
> On Tue, Jul 05, 2016 at 03:34:20PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 05/07/2016 15:04, Eduardo Habkost wrote:
>>> On Tue, Jul 05, 2016 at 09:51:41AM -0300, Marcelo Tosatti wrote:
>>>> On Mon, Jul 04, 2016 at 04:45:06PM -0300, Eduardo Habkost wrote:
>>>>> On Mon, Jul 04, 2016 at 04:30:08PM -0300, Marcelo Tosatti wrote:
>>>>>> On Mon, Jul 04, 2016 at 01:01:42PM +0200, Paolo Bonzini wrote:
>>>>>>> Can bad things happen if a guest using the TSC deadline timer is
>>>>>>> migrated?  The guest doesn't re-calibrate the TSC after migration, and
>>>>>>> the TSC frequency can and will change unless your data center is
>>>>>>> perfectly homogeneous.
>>>>>>
>>>>>> It can fire earlier if the destination runs at a higher frequency.
>>>>>> It will fire past the configured time if the destination runs at a slower frequency.
>>>>>>
>>>>>> Suppose the first case is worse.
>>>>>>
>>>>>> Should convert the expiration time to nanoseconds i suppose, and then 
>>>>>> convert back on the destination.
>>>>>
>>>>> This won't make any difference if the guest sets up a new timer
>>>>> after migration (but using the old TSC frequency), will it?
>>>>
>>>> It does, because the timer setup traps to the host, where you can
>>>> convert it to the proper value:
>>>
>>> To convert it to the proper value, you need to know what's the
>>> TSC frequency the guest is assuming. How would you do that?
>>
>> In theory with KVM_SET_TSC_KHZ, but it has to be specified manually and
> 
> Just read the TSC value where the guest has booted and migrate that.

Right, QEMU 2.6 does that.

But even worse, instead of tsc_always_catchup you get a WARN if the user
requests a TSC rate below hardware spped.

>> I'd like to make KVM_SET_TSC_KHZ fail if TSC scaling is not supported by
>> the processor.
> 
> Thats a good idea.

Good!

Paolo