Quoting Christian Borntraeger (2022-09-20 13:07:58)
> Am 29.08.22 um 09:56 schrieb Nico Boehr:
> > When running under PV, the guest's TOD clock is under control of the
> > ultravisor and the hypervisor isn't allowed to change it. Hence, don't
> > allow userspace to change the guest's TOD clock by returning
> > -EOPNOTSUPP.
> >
> > When userspace changes the guest's TOD clock, KVM updates its
> > kvm.arch.epoch field and, in addition, the epoch field in all state
> > descriptions of all VCPUs.
> >
> > But, under PV, the ultravisor will ignore the epoch field in the state
> > description and simply overwrite it on next SIE exit with the actual
> > guest epoch. This leads to KVM having an incorrect view of the guest's
> > TOD clock: it has updated its internal kvm.arch.epoch field, but the
> > ultravisor ignores the field in the state description.
> >
> > Whenever a guest is now waiting for a clock comparator, KVM will
> > incorrectly calculate the time when the guest should wake up, possibly
> > causing the guest to sleep for much longer than expected.
> >
> > With this change, kvm_s390_set_tod() will now take the kvm->lock to be
> > able to call kvm_s390_pv_is_protected(). Since kvm_s390_set_tod_clock()
> > also takes kvm->lock, use __kvm_s390_set_tod_clock() instead.
> >
> > Fixes: 0f3035047140 ("KVM: s390: protvirt: Do only reset registers that are accessible")
> > Signed-off-by: Nico Boehr <nrb@xxxxxxxxxxxxx>
>
> Has this patch already been sent to the upstream list yet and have we solved all existing problems of the previous version?
Yes, the patch works and the issues I identified should be fixed now. I can resend as a non-RFC if you like.
Note that a QEMU change is also needed to silence this message:
warning: Unable to set KVM guest TOD clock: Operation not supported
But I wanted to get the kernel side done first.
