On 08.10.14 16:09, Jason Herne wrote: > Christian Borntraeger <borntraeger@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
