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

[Ian Campbell <Ian.Campbell@citrix.com>]

On Sat, 2013-05-18 at 10:52 +0100, Alex Bligh wrote:
> Ian,
> 
> --On 17 May 2013 18:33:48 +0100 Ian Campbell <ian.campbell@citrix.com> 
> wrote:
> 
> > On Tue, 2013-05-14 at 14:12 +0100, Diana Crisan wrote:
> >> Prior to issuing a migration the lines 'platform = ""', 'acpi = "1"',
> >> 'acpi_s3 = "1"' and 'acpi_s4 = "1"' are present in xenstore (despite
> >> the fact xl.conf does not explicitly specify them). However, after the
> >> migration succeeds on the receiving side, those lines are missing.
> >
> > Is the lack of these keys causing you a problem? IIRC they are used by
> > the builder to communicate with hvmloader (the pre-BIOS loader used in
> > HVM guests) so it can setup ACPI tables etc as appropriate. Nothing else
> > should be using them. They are documented as INTERNAL in
> > docs/misc/xenstore-paths.markdown.
> 
> (Diana is my colleague)
> 
> We don't know whether it causes a problem, but we were looking to
> find something something that might explain the stuck clock on migration
> Diana reported along side this on ACPI enabled hvm:
>  http://lists.xen.org/archives/html/xen-devel/2013-05/msg01472.html
> 
> We figured if ACPI wasn't being set up right on the recipient (migrated)
> domain, this might be the problem (given the stuck clock only appears
> if you use ACPI).
> 
> How does the recipient upstream QEMU / Xen know whether to emulate
> ACPI if this is not transferred?

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.

Ian.