On 20.02.2018 16:15, Christian Borntraeger wrote:
>
>
> On 02/07/2018 12:46 PM, David Hildenbrand wrote:
>> Right now, SET CLOCK called in the guest does not properly take care of
>> the epoch index, as the call goes via the old kvm_s390_set_tod_clock()
>> interface. So the epoch index is neither reset to 0, if required, nor
>> properly set to e.g. 0xff on negative values.
>>
>> Fix this by providing a single kvm_s390_set_tod_clock() function. Move
>> Multiple-epoch facility handling into it.
>>
>
> POP says
>
>
> The SET CLOCK instruction provides no means
> by which an epoch index can be set. When the
> multiple-epoch facility is installed, the use of SET
> CLOCK may result in inconsistent values stored
> by STORE CLOCK EXTENDED if the epoch
> index was previously set to a nonzero value. In
> this case, the PTFF control function PTFF-STOE
> (set TOD offset extended) should be used rather
> than SET CLOCK.
>
> At some future date, the SET CLOCK instruction
> may be removed from the architecture.
>
>
> so I think we are compliant, no?
>
/* KVM: epoch_idx = 0; epoch = 0 */
get_tod_clock_ext(&idx, &tod);
/* assume idx == 0, some time passes */
set_tod_clock(tod);
/* e.g. epoch_idx = 0, epoch = -1 */
get_tod_clock_ext(&idx, &tod);
/* as we missed to set epoch_idx to -1, we can now get idx=1 */
Or am I wrong? The guest never modified the epoch index ("if the epoch
index was previously set to a nonzero value").
--
Thanks,
David / dhildenb
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
