Re: HVM Migration of domU on Qemu-upstream DM loses ACPI data in xenstore

[Diana Crisan <dcrisan@flexiant.com>]

Hello Ian,

>On Mon, 2013-05-20 at 12:50 +0100, Alex Bligh wrote:
>> Ian,
>> 
>> --On 20 May 2013 09:40:01 +0100 Ian Campbell <Ian.Campbell@citrix.com> 
>> wrote:
>> 
>> > You could perhaps verify this somewhat by playing with the kernel's
>> > clocksource= option.
>> 
>> clocksource=[hpet|pit|tsc|acpi_pm|cyclone|scx200_hrt]
>> 
>> I'm guessing clocksource=tsc is the least dependent on 'other stuff'.

>It'd be a good one to start with. You should be able to confirm under
>sysfs which one is used now, I'm guessing it is acpi_pm.

>It'd be worth trying each of the first 4 though. cyclone and scx200 seem
>a bit specific...

I tested the first 4 options with both xen 4.2 and xen 4.3. Please see below my findings:

Under 4.2:
tsc: cannot use this as not HRT compatible; can't switch while in HRT/NOHZ mode
hpet: activated according to dmesg; after migration got this error:
"i8042 no controller found; pm: device i8042 failed to restore: error -19"
and this error (??) got the clock stuck again
pit: did not get an error, but it did not seem to have listened to my request as I could see in dmesg it reading my request to switch to clocksource=pit but choosing to set the xen clocksource.


Under 4.3:
tsc: as above, not HRT compatible so cannot use it.
hpet: still get the clock stuck after several migrations (3-4 migrations)
pit: as above it is ignored.
acpi_pm: it seems to be easier to replicate the problem with this clocksource - got it on the first migrate.


Notes: the wallclock (date) and RTC  (clock -r) on the hosts were in sync within a second


>> We'll have a play.
>> 
>> >> Any ideas on how to debug this further? It is odd that the date command
>> >> (used to set a date) will unstick the clock.
>> >
>> > I'd have thought that would only poke the RTC, but to be honest I'm not
>> > sure.
>> 
>> I'm pretty sure date itself only changes the wallclock (the clock command
>> normally being needed to write to the RTC).

>Yes, I think you are right.

>>  If the images are running
>> ntp, that may notice the wallclock change and write to CMOS I guess.


Please let me know if you need any more details.

-- 
Diana Crisan