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 <etha...@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
