Re: [PATCH] qemu-options.hx: Fix reversed description of icount sleep behavior

[Peter Maydell]

On Fri, 6 Jun 2025 at 10:58, Ethan Chen via <qemu-devel@nongnu.org> wrote:
>
> The documentation for the -icount option incorrectly describes the behavior
> of the sleep suboption. Based on the actual implementation and system
> behavior, the effects of sleep=on and sleep=off were inadvertently reversed.
> This commit updates the description to reflect their intended functionality.
>
> Signed-off-by: Ethan Chen <ethan84@andestech.com>
> ---
>  qemu-options.hx | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 7eb8e02b4b..1f862b19a6 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4936,13 +4936,13 @@ SRST
>      with actual performance.
>
>      When the virtual cpu is sleeping, the virtual time will advance at
> -    default speed unless ``sleep=on`` is specified. With
> -    ``sleep=on``, the virtual time will jump to the next timer
> +    default speed unless ``sleep=off`` is specified. With
> +    ``sleep=off``, the virtual time will jump to the next timer
>      deadline instantly whenever the virtual cpu goes to sleep mode and
>      will not advance if no timer is enabled. This behavior gives
>      deterministic execution times from the guest point of view.
> -    The default if icount is enabled is ``sleep=off``.
> -    ``sleep=on`` cannot be used together with either ``shift=auto``
> +    The default if icount is enabled is ``sleep=on``.
> +    ``sleep=off`` cannot be used together with either ``shift=auto``
>      or ``align=on``.

Whoops. It looks like I introduced this error in commit fa647905e6baae
where I converted the previous unhelpful "sleep=on|off" to say
specifically whether it meant sleep=on or sleep=off: I got it
the wrong way around.

Confirmed against the icount-common.c code that our default is
indeed sleep=on and that the incompatibility with shift=auto
and align=on is the sleep=off setting.

Applied to target-arm.next, thanks.

-- PMM