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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sat, 2013-05-18 at 12:17 +0100, Alex Bligh wrote:
> Ian,
> 
> --On 18 May 2013 12:02:23 +0100 Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
> 
> > These keys have nothing to do with that, all they do is cause hvmloader
> > to expose ACPI tables to the guest or to tweak the content of those
> > tables. That state is preserved as part of the memory image of the
> > guest. The qemu state is also pickled as part of the save image.
> >
> > ACPI is jut a set of tables describing the hardware, there's no
> > "emulation" to turn off and on. Whatever magic I/O ports the ACPI AML
> > references are always on, the setting just controls whether the guest
> > gets to see that via the AML.
> 
> Thanks. So it could not be that the guest gets to see that via the AML
> pre migration, but not post migration?

AML lives in guest RAM, so no.

> In that case I can only conclude that some part of the qemu state
> is not migrating correctly, and the fact that it the cluck stock
> doesn't happen if ACPI is enabled in xl.conf is only relevant as
> it influences how the guest (linux in this case) chooses its clock
> source (i.e. its broken in any case, just the guest does not notice
> if the relevant ACPI dtables aren't exposed).

You could perhaps verify this somewhat by playing with the kernel's
clocksource= option.

Most (all?) of the clocks are actually emulated by the hypervisor rather
than qemu for performance reasons, but that state is also pickled over a
migrate.

> 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.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel