On Sun, Mar 2, 2025 at 2:22 AM Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > > On Fri, Feb 21, 2025 at 02:39:27PM +0900, Suleiman Souhlal wrote: > > When the host resumes from a suspend, the guest thinks any task > > that was running during the suspend ran for a long time, even though > > the effective run time was much shorter, which can end up having > > negative effects with scheduling. > > > > To mitigate this issue, the time that the host was suspended is included > > in steal time, which lets the guest can subtract the duration from the > > s/can// > > tasks' runtime. > > > > In order to implement this behavior, once the suspend notifier fires, > > vCPUs trying to run block until the resume notifier finishes. This is > > s/run/run will/ > > because the freezing of userspace tasks happens between these two points, > Full stop at the end of that ^ > > which means that vCPUs could otherwise run and get their suspend steal > > time misaccounted, particularly if a vCPU would run after resume before > > the resume notifier. > > s/notifier/notifier fires/ > > > Incidentally, doing this also addresses a potential race with the > > suspend notifier setting PVCLOCK_GUEST_STOPPED, which could then get > > cleared before the suspend actually happened. > > > > One potential caveat is that in the case of a suspend happening during > > a VM migration, the suspend time might not be accounted. > > s/accounted/accounted for./ > > A workaround would be for the VMM to ensure that the guest is entered > > with KVM_RUN after resuming from suspend. > > So ..does that mean there is a QEMU patch as well? No, I am not planning on making a QEMU patch. A QEMU patch would only be needed if you cared about the caveat mentioned there. Thanks, -- Suleiman
