Pavel Dovgalyuk, le mar. 31 juil. 2018 09:58:26 +0300, a ecrit: > > From: Samuel Thibault [mailto:samuel.thiba...@gnu.org] > > Pavel Dovgalyuk, le jeu. 26 juil. 2018 11:37:57 +0300, a ecrit: > > > Or the timers are related to the network devices (e.g., servers in the > > > outer world)? > > > > No. > > > > > > > > > this service is not related to the guest state. > > > > > > > > seems incorrect. At the moment the ip6_icmp timer's current value is not > > > > saved in the guest state, but in principle it should, so that the guest > > > > does see the RAs at a regular rate. In practice we don't care because > > > > the timing is randomized anyway. > > > > > > Isn't this just a side effect? > > > I mean that slirp may be replaced by, say, tap, and the guest should not > > > notice > > > the difference. > > > > Well, if a guest is connected through a tap, the virtual time should > > really run as fast as the realtime, and it should not be paused. > > Otherwise TCP connections will break since the guest won't be able to > > reply fast enough, without even knowing about the issue. Slirp can > > compensate this thanks to a buffer between what happens in the real > > world and what happens in the virtual world. Real world timings are > > handled by the OS socket implementation, and virtual world timings are > > handled with the qemu timer. > > Then maybe the solution is the new clock with the frequency of the virtual > clock, but which does not affect the replayed core? > This clock should stop when VM is paused. > It also could be saved in vmstate. As it does not affect the replay, > saving and restoring its state won't break anything.
I guess so. Samuel