Am 08.10.2014 16:55, schrieb Alexander Graf: > > > 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 :). Yes, that is usally always the right thing to do with Linux :-) Jason, can you post the minimal patch that used SET_CLOCK/GET_CLOCK to set/get the bits 0-63 of the TOD? (also apply it internally so that we can test it for some days. Its too late for this merge window anyway.) If we want some different scheme, we can certainly discuss extension via the flags (and pad) in the future. So this interface is certainly not a dead end if we need more I have 2 possible extension in mind: 1. the thing that we discussed, lets see if we need a fix or not 2. making KVM on s390x ready for 2042 and beyond (there is no architecture yet but STCKE stores a byte of zeroes to the left of the TOD clock value. So I guess if this is extended somewhen we might want an additional flag plus a maximum of 1 additional byte. There is plenty of pad space so this is fine Christian -- 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
