Re: [[RFC] KVM-S390: Provide guest TOD Clock Get/Set Controls

[Alexander Graf <agraf@suse.de>]

On 08.10.14 16:09, Jason Herne wrote:
> Christian Borntraeger <borntraeger@de.ibm.com> wrote on 09/22/2014
> 05:08:34 AM:
> ...
>> Actually, I would expect something different (more or less something
>> like standby/resume).
>>
>> In fact Jasons code that we have internally in testing is doing the
>> simple approach
>> 1. source reads guest time at migration end
>> 2. target sets guest time from source
>>
>> So we have the guarantee that the time will never move backwards. It
>> also works quite well for migration. As a bonus, we could really
>> reuse the existing ioctl.
>>
>> I asked Jason to explore alternatives, though: I think it is somehow
>> wrong, if you save a guest into an image file, open that one month
>> later and the guest will always be 1 month behind unless it uses
>> some kind of ntp. If everybody agrees that this is fine, I will
>> queue up Jasons intial patch (simple get/set).
>> The only question is then: shall we use an s390 specific ioctl (e.g.
>> via VM attribute) or just use the existing KVM_SET_CLOCK.
>> But maybe lets answer the first question before we decide on this.
> 
> Ping. Does anyone feel strongly about this issue? I'm interested in
> opinions so we can get s390 TOD clock migration working :).
> 
> We need to decide which interface to use, s390 specific ioctl or
> KVM_SET_CLOCK.

I don't have any particular preference. If anything, I'm leaning towards
KVM_SET_CLOCK.

> Then we need to decide if we're going to snap a guest clock forward
> on the resume of a "suspend to disk" type operation. The alternative
> is to fix up the guest TOD value such that the guest notices no
> change of time, which as Christian points out, seems wrong. Unless we
> really want to show no time change and force the guest to use ntp to
> figure out that he is behind.

Just do it the same as x86 :).


Alex