HVM Migration of domU on Qemu-upstream DM causes stuck system clock with ACPI

[Diana Crisan <dcrisan@flexiant.com>]

This is problem 1 of 3 problems we are having with live migration and/or ACPI on Xen-4.3 and Xen-4.2.

Any help would be appreciated.

Detailed description of problem:

We are using Xen-4.3-rc1 with dom0 running Ubuntu Precise and 3.5.0-23-generic kernel, and domU running Ubuntu Precise (12.04) cloud images running 3.2.0-39-virtual. We are using the xl.conf below on qemu-upstream-dm and HVM and two identical sending and receiving machines (hardware and software)

When live migration is instigated between two identical hardware configurations using 'xl migrate', the migrate completes but the system clock in domU appears to be stuck when the domU resumes on the receiving side. For instance, running 'top', 'date', or 'uptime' will constantly report the same result. The clocks in dom0 were synchronized before migration using ntpdate. A modification of the clock using the date command in the migrated domU solves the problem; migrating back to the original machine works, but after a third migration the problem reappears. 

Sometimes the clock is not stuck on the first migrate, but the problem is reproducible after several migrations.

How to replicate:

1. Take two machines with identical hardware and software, running the xen-4.3-rc1 version of Xen on Ubuntu Precise with 3.5.0-23-generic kernel.
2. Use the xl.conf below as a configuration file.
3. Create a VM using Ubuntu Precise and 3.5.0-23 generic.
4. Start the VM
5. xl migrate from one to the other
6. wait until it resumes on the receiving side
7. Determine whether the clock is updating (run 'top'). Determine whether ping works (ping is broken if the clock is stopped).
8. Repeat steps 5, 6 and 7 multiple times until the clock is stuck (usually happens within 3 migrations)

Expected results:

The clock is never stuck

Actual results:

The clock becomes 'stuck' after one or more migrations

Notes:

If the lines 'acpi=0', 'acpi_s3=0', 'acpi_s4=0' are added to xl.conf, I cannot reproduce this problem. I thus believe it may be something to do with ACPI. In investigating this, we found problem (2) which is that live migration does not take across all the acpi entries within xenstore - this is handled in a separate email.

On xen-4.2, a similar thing happens. However, if the clock does become stuck, the subsequent migration fails.

--xl.conf--

builder='hvm'
memory = 512
name = "416-vm"
vcpus=1
disk = [ 'tap:qcow2:/root/diana.qcow2,xvda,w' ]
vif = ['mac=00:16:3f:1d:6a:c0, bridge=defaultbr']
sdl=0
opengl=1
vnc=1
vnclisten="0.0.0.0"
vncdisplay=0
vncunused=0
vncpasswd='p'
stdvga=0
serial='pty'