The current documentation is fairly terse and not easy to decode for someone who's not intimately familiar with the inner workings of timer devices. Expand on it by providing a somewhat verbose description of what behavior each policy will result in, as seen from both the guest OS and host point of view. This is lifted directly from QEMU commit commit 2a7d957596786404c4ed16b089273de95a9580ad Author: Andrea Bolognani <abologna@redhat.com> Date: Tue Feb 11 19:37:44 2020 +0100 qapi: Expand documentation for LostTickPolicy v4.2.0-1442-g2a7d957596 The original text also matched word for word the documentation found in QEMU. Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- docs/formatdomain.html.in | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index f4af65f13f..4fef2a0a97 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -2487,26 +2487,36 @@ <p> The <code>tickpolicy</code> attribute determines what happens when QEMU misses a deadline for injecting a - tick to the guest: + tick to the guest. This can happen, for example, because the + guest was paused. </p> <dl> <dt><code>delay</code></dt> - <dd>Continue to deliver ticks at the normal rate. - The guest time will be delayed due to the late - tick</dd> + <dd>Continue to deliver ticks at the normal rate. The guest OS + will not notice anything is amiss, as from its point of view + time will have continued to flow normally. The time in the + guest should now be behind the time in the host by exactly + the amount of time during which ticks have been missed.</dd> <dt><code>catchup</code></dt> - <dd>Deliver ticks at a higher rate to catch up - with the missed tick. The guest time should - not be delayed once catchup is complete.</dd> + <dd>Deliver ticks at a higher rate to catch up with the missed + ticks. The guest OS will not notice anything is amiss, as + from its point of view time will have continued to flow + normally. Once the timer has managed to catch up with all + the missing ticks, the time in the guest and in the host + should match.</dd> <dt><code>merge</code></dt> <dd>Merge the missed tick(s) into one tick and inject. The guest time may be delayed, depending on how the OS reacts to the merging of ticks</dd> <dt><code>discard</code></dt> - <dd>Throw away the missed tick(s) and continue - with future injection normally. The guest time - may be delayed, unless the OS has explicit - handling of lost ticks</dd> + <dd>Throw away the missed ticks and continue with future + injection normally. The guest OS will see the timer jump + ahead by a potentially quite significant amount all at once, + as if the intervening chunk of time had simply not existed; + needless to say, such a sudden jump can easily confuse a + guest OS which is not specifically prepared to deal with it. + Assuming the guest OS can deal correctly with the time jump, + the time in the guest and in the host should now match.</dd> </dl> <p>If the policy is "catchup", there can be further details in the <code>catchup</code> sub-element.</p> -- 2.24.1