Pavel Dovgalyuk, le jeu. 26 juil. 2018 10:37:03 +0300, a ecrit: > > From: Samuel Thibault [mailto:samuel.thiba...@gnu.org] > > Pavel Dovgalyuk, le jeu. 26 juil. 2018 10:08:29 +0300, a ecrit: > > > > As documented: > > > > > > > > * @QEMU_CLOCK_REALTIME: Real time clock > > > > * > > > > * The real time clock should be used only for stuff which does not > > > > * change the virtual machine state, as it runs even if the virtual > > > > * machine is stopped. > > > > > > > > There is no reason to "send RAs" while the machine is stopped. > > > > > > I see. > > > Then we'll need one more clock. Which works like realtime+virtual: > > > intended to be used for the internal QEMU purposes, but stops when > > > VM is stopped. > > > > Just to be sure: what is meant by "is stopped"? Is it a pause (thus time > > does not advance within the guest), or is it just sleeping because it > > has nothing to do? > > Paused with HMP/QMP command. > As virtual clock runs only if VM is not paused.
Then all other uses of qemu_clock in slirp are bogus and need to be fixed like ip6_icmp: they are using QEMU_CLOCK_REALTIME, but they want it not to progress while the guest time is not advancing. Otherwise on guest resume after a long pause basically all TCP/UDP/ARP timings will have expired. Samuel
