Am 06.11.2014 09:43, schrieb Christian Borntraeger:
> Am 05.11.2014 20:45, schrieb Paolo Bonzini:
>>
>>
>> On 05/11/2014 18:56, Christian Borntraeger wrote:
>>>>>
>>>>> Whether you want to follow that approach or do it as VM attribute
>>>>> straight away, I don't mind much :).
>>> given that top programmable field and epoch are available as ONEREG, lets 
>>> do the same for TOD.
>>
>> Is the epoch per-cpu?
> 
> two answers :-)
> 
> - the implementation is one epoch per control block, so someone could do that 
> per CPU...but:
> - guest TOD == host TOD + epochdiff. architecture mandates that there is only 
> one TOD per system, so all guest TODs must be synced and so must be all 
> epochdiffs
> 
> Some background. We provided access to the epoch value about 2 years ago with 
> other things as ONEREG. Asumming that all hosts are time synced, we could 
> just migrate the epoch value.
> Now: this is not the case all the time. Just migrating the epoch could result 
> in time jumping forth and back.
> 
> This thing is now: QEMU cannot calculate a correction reliably, because it 
> cannot rely on the value of the TOD (by using stck) since the kernel might do 
> tricks with the host TOD value as soon as we enable time synching between z 
> boxes.
> (Thats why normal userspace should not use stck either, it should use 
> gettimeofday because the kernel might have offsets etc due to NTP or time 
> synching between boxes). So we finally cam up with just migrating the guest 
> visible TOD, which seems to work fine.
> 
> As a recap we have now:
> #define KVM_REG_S390_TODPR     (KVM_REG_S390 | KVM_REG_SIZE_U32 | 0x1)
> #define KVM_REG_S390_EPOCHDIFF (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x2)
> 
> and we would
> add
> #define KVM_REG_S390_TOD       (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x3) 
> #define KVM_REG_S390_TOD_INDEX (KVM_REG_S390 | KVM_REG_SIZE_U8 | 0x4)

obviously not 0x3 and 0x4 but something higher..

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to