artificially advancing guest clock

[Patrick Hemmer]

I'm wondering if it's possible to programmatically advance the clock of a QEMU guest. For example I want to advance the clock as if X ms real time had passed, such that calls like `sleep()`, `clock_gettime()`, `gettimeofday()`, `epoll_wait(,,,timeout)`, etc, all behave as if the time had actually elapsed, and that short of an NTP call, the guest would be unable tell the clock is wrong.

What I'm trying to do is replay recorded network activity against an application. The duration between each recorded event is important, so I can't just play it back at full speed. However if that record contains hours worth of data, I don't want to have to take hours to perform the replay. So my goal is that after each event is processed, and the app is waiting for the next one, I want to skip the clock ahead so the app thinks that time has passed.

Controlling the clock from inside the guest via the kernel doesn't work. In calls like `sleep()` and `clock_gettime(CLOCK_MONOTONIC,)`, the kernel is smart enough to know that if you manually advance the clock, that time didn't actually pass, and so the calls operate as if nothing happened.

My theory is that since VM guests can have indeterminate periods of time in which they don't get CPU time scheduled, and that they must properly handle that gap when they are next scheduled, I could abuse that mechanism to make the guest think that time had passed, and that it just didn't get scheduled CPU time. However I'm not sure of the internal mechanics of how the kernel interacts with the RTC, how it's provided by QEMU, how the guest kernel detects gaps in VM scheduling, etc.

Is what I'm trying possible? If so, can someone point me in the general direction on where to start?

Thanks

--

Patrick Hemmer