Under PV, the guest's TOD clock is under control of the ultravisor and the
hypervisor cannot change it.

With upcoming kernel changes[1], the Linux kernel will reject QEMU's
request to adjust the guest's clock in this case, so don't attempt to set
the clock.

This avoids the following warning message on save/restore of a PV guest:

warning: Unable to set KVM guest TOD clock: Operation not supported

[1] https://lore.kernel.org/all/20221011160712.928239-2-nrb@linux.ibm.com/

Fixes: c3347ed0d2ee ("s390x: protvirt: Support unpack facility")
Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
---
 hw/s390x/tod-kvm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/hw/s390x/tod-kvm.c b/hw/s390x/tod-kvm.c
index 9d0cbfbce2bf..303bd67ee64f 100644
--- a/hw/s390x/tod-kvm.c
+++ b/hw/s390x/tod-kvm.c
@@ -13,6 +13,7 @@
 #include "qemu/module.h"
 #include "sysemu/runstate.h"
 #include "hw/s390x/tod.h"
+#include "hw/s390x/pv.h"
 #include "kvm/kvm_s390x.h"
 
 static void kvm_s390_get_tod_raw(S390TOD *tod, Error **errp)
@@ -84,6 +85,13 @@ static void kvm_s390_tod_vm_state_change(void *opaque, bool running,
     S390TODState *td = opaque;
     Error *local_err = NULL;
 
+    /*
+     * Under PV, the clock is under ultravisor control, hence we cannot restore
+     * it on resume.
+     */
+    if (s390_is_pv())
+        return;
+
     if (running && td->stopped) {
         /* Set the old TOD when running the VM - start the TOD clock. */
         kvm_s390_set_tod_raw(&td->base, &local_err);
-- 
2.36.1

On 12/10/2022 14.32, Nico Boehr wrote:
> Under PV, the guest's TOD clock is under control of the ultravisor and the
> hypervisor cannot change it.
> 
> With upcoming kernel changes[1], the Linux kernel will reject QEMU's
> request to adjust the guest's clock in this case, so don't attempt to set
> the clock.
> 
> This avoids the following warning message on save/restore of a PV guest:
> 
> warning: Unable to set KVM guest TOD clock: Operation not supported
> 
> [1] https://lore.kernel.org/all/20221011160712.928239-2-nrb@linux.ibm.com/
> 
> Fixes: c3347ed0d2ee ("s390x: protvirt: Support unpack facility")
> Signed-off-by: Nico Boehr <nrb@linux.ibm.com>
> ---
>   hw/s390x/tod-kvm.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/hw/s390x/tod-kvm.c b/hw/s390x/tod-kvm.c
> index 9d0cbfbce2bf..303bd67ee64f 100644
> --- a/hw/s390x/tod-kvm.c
> +++ b/hw/s390x/tod-kvm.c
> @@ -13,6 +13,7 @@
>   #include "qemu/module.h"
>   #include "sysemu/runstate.h"
>   #include "hw/s390x/tod.h"
> +#include "hw/s390x/pv.h"
>   #include "kvm/kvm_s390x.h"
>   
>   static void kvm_s390_get_tod_raw(S390TOD *tod, Error **errp)
> @@ -84,6 +85,13 @@ static void kvm_s390_tod_vm_state_change(void *opaque, bool running,
>       S390TODState *td = opaque;
>       Error *local_err = NULL;
>   
> +    /*
> +     * Under PV, the clock is under ultravisor control, hence we cannot restore
> +     * it on resume.
> +     */
> +    if (s390_is_pv())
> +        return;

  Hi Nico,

I know it's annoying when switching between kernel coding style and QEMU 
coding style, but please use curly braces when doing QEMU patches. I wonder 
why checkpatch.pl does not print any warnings here...?

Anyway, since it's a trivial patch, I fixed it up on my own and queued your 
patch to my s390x-next branch:

  https://gitlab.com/thuth/qemu/-/commits/s390x-next/

  Thomas

Quoting Thomas Huth (2022-10-17 09:30:04)
[...]
> I know it's annoying when switching between kernel coding style and QEMU 
> coding style, but please use curly braces when doing QEMU patches. I wonder 
> why checkpatch.pl does not print any warnings here...?

Ooops, sorry for the oversight. You are right, thanks for making me aware of the
different coding styles.