On 25/06/20 16:26, Kevin Locke wrote: > I'm trying to understand the cause and what options might exist for > addressing it. Several questions: > > 1. Do I understand correctly that the CPU usage is due to counting > RTC periodic timer ticks for replay when the guest is resumed? Yes. > 2. If so, would it be possible to calculate the number of ticks > required from the time delta at resume, rather than polling each > tick while paused? Note that high CPU usage while the guest is paused is a bug. Only high CPU usage as soon as the guest resumes is the unavoidable part. That's because Windows (at least older version) counts up by one for every tick and so we have to inject thousands of ticks for it to catch up. > 3. Presumably when restoring from a snapshot, Windows time must jump > forward from the time the snapshot was taken. How does this differ > from resuming from a paused state? It doesn't, and it sucks equally bad because you get high CPU usage as soon as the snapshot is restored (in order to catch up with possibly days of lost ticks!). > 4. How is this handled if the host is suspended (S3) when the VM is > paused (or not paused) and ticks aren't counted on the host? During S3, the VM is paused in a reset state (so all timers are off, which might explain different/non-buggy behavior). After wakeup, Windows refreshes the clock from the RTC time of day. > 5. I have not observed high CPU usage for paused VMs in VirtualBox. > Would it be worth investigating how they handle this? > > From the discussion in https://bugs.launchpad.net/bugs/1851062 it > appears that the issue does not occur for all Windows 10 VMs. Does > that fit the theory it is caused by RTC periodic timer ticks? Windows 10 can use the Hyper-V synthetic timer instead of the RTC, which shouldn't have the problem. Paolo
