[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH] target/ppc: only save guest timebase

From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH] target/ppc: only save guest timebase once after stopping
Date: Fri, 27 Jul 2018 13:35:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 27/07/18 02:10, David Gibson wrote:

Right, I agree.  Migrating shouldn't advance the time if we've already
explicitly stopped.  But it's not really clear how to accomplish that

This topic is obviously of interest to me because it relates to various discussions in the past relating to migrating guest timebases under TCG, so below is my current understanding of what we are trying to achieve.

Using the following assumptions:

  i) Sending host and receiving host have the same TB freq
 ii) Sending host and receiving host have synchronised clocks

If we ignore any RTC issues for the moment (can we assume that the guest will resync itself via NTP or similar on restart?) then it is possible to model 2 separate scenarios:

1) Guest is stopped

In this case there is no timebase compensation required on the receiving host. When restarted the guest will see the same timebase as at the point in time in which it was stopped.

  When guest is stopped:
    guestTB = sendHostTB + sendHostTBDiff

  When guest moves to running state:
    recvTBDiff = guestTB - recvHostTB

2) Guest is running

In this case the duration of the migration itself must be considered when the guest starts executing on the receiver. Since the guest is running the resulting guestTB is compensated for the time spent during the migration phase itself.

  guestTB = sendHostTB + sendHostTBDiff
  sendhostCLK = qemu_clock_get_ns(QEMU_CLOCK_REALTIME)

  When guest moves to running state:
    recvhostCLK = qemu_clock_get_ns(QEMU_CLOCK_REALTIME)
    migrationTime = recvhostCLK - sendhostCLK
    migrationTBDiff = migrationTime / recvHostTBFreq
    recvTBDiff = guestTB + migrationTBDiff - recvHostTB

The VM running state should already be in the migration stream which enables the receiving host to determine between scenarios 1 and 2, and in fact they are equivalent if migrationTime is considered to be 0 in scenario 1.

There is also the issue as to whether to allow migration between hosts with different timebases; it should be possible to calculate the correct recvTBDiff if sendTBFreq were included in the migration stream, but could the guest OS detect this and change its behaviour accordingly?

Perhaps a solution here is to always have a separate field representing the guestTB the last time the VM was stopped (stoppedGuestTB?) set via a VM state change handler and include it in the migration stream?

The receiver knows whether the incoming guest is running or not, and so can choose whether to use stoppedGuestTB (set at the last VM stop) or guestTB (set during timebase_save) for its timebase calculations when resuming the guest as required?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]