Re: [Qemu-devel] [PATCH v1] s390x/tod: properly stop the KVM TOD while the guest is not running

[David Hildenbrand <david@redhat.com>]

On 27.11.18 13:43, Christian Borntraeger wrote:
> On 27.11.2018 12:41, David Hildenbrand wrote:
>> Just like on other architectures, we should stop the clock while the guest
>> is not running. This is already properly done for TCG. Right now, doing an
>> offline migration (stop, migrate, cont) can easily trigger stalls in the
>> guest.
>>
>> Even doing a
>>     (hmp) stop
>>     ... wait 2 minutes ...
>>     (hmp) cont
>> will already trigger stalls.
>>
>> So whenever the guest stops, backup the KVM TOD. When continuning to run
>> the guest, restore the KVM TOD.
> 
> We do a similar thing for managedsave so it probably makes sense to solve
> the stall warnings. Now: At the same time, we actually want to have the guest
> see the real time and maybe even share the TOD clock with the host in some
> way, while at the same time avoid the stall warnings.

managedsave works right now because we save/restore the TOD. Making the
guest TOD jump is never a good idea. At least not blindly (as you
mention below, special SCLP signals eventually).

> 
> One idea is to signal the guest on migration (and stop start events) and let
> the guest do a time sync with the host.

Doing so on stop events will most likely kill the ability to debug (e.g.
single step) your guest. You will trap into the SCLP signal handler in
the guest all the time. I don't think this is a good idea for the
general case. It might be for migration. We might instead want to handle
this in KVM directly and not in QEMU.

> In fact, it seems that by architecture we need to signal a special sclp signal 
> anyway if stsi information would change (e.g. on migration). Maybe we can 
> piggyback on that and do some time sync interface in the future.

I like the idea but I rather consider it an addon feature and that
shouldn't be the default.

As SCLP documentation is (as far as I know, please correct me if I am
wrong) not publicly available, I suggest going ahead with what I propose
here (what other architectures do) and implementing what you describe on
top later.

Thanks!

-- 

Thanks,

David / dhildenb