On Wed, Jul 25, 2018 at 02:32:11PM +0200, Igor Mammedov wrote: > On Tue, 10 Jul 2018 03:01:30 +0300 > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > Now that basic support for guest CPU PM is upstream, I started looking > > for making it migrateable. Since a VM can be migrated between different > > hosts, PM info needs to change each time with move the VM to a different > > host. > Considering notification is async, so there will be a window when > guest will be using old Cstates on new host. What will happen if > machine is migrated to host that doesn't support a Cstate > that was used on source when guest was started?
My testing shows mwait with a wrong hint works, presumably it just uses a lot of power. > > This adds infrastructure - based on Load/Unload - to support exactly > > that: QEMU generates AML (changing it on migration) and stores it in > > reserved memory, OSPM loads _CST from there on demand. > Cool and very tempting idea but I have 2 worries about this approach: > 1. How well does it work with Windows based guests? > (I've tried something similar but generating new AML from AML itself > to get rid of our long if/else chains there to make up Notify target name. > I ditched it (unfortunately I don't recall why) ) After trying it, I can tell you why - it's a horrid mess of unreadable code, with arbitrary restraints on package length etc. > 2. (probably biggest issue) Loading dynamically generated AML > basically would make all AML code ABI, so that static AML > in RAM of old QEMU version would match dynamic generated > one on target side with new QEMU (/me generalizing approach beyond _CST > support). > I'd try to keep our AML version less as much as possible > and go this route only if there is no other way to do it. That's a good point, thanks for bringing this up! So it seems that we will need to define the ABI, yes. All AML code is an over-statement though, there are specific entry points we must maintain, right? And that in the end isn't fundamentally different from the ABIs mandated by the ACPI spec. So I have these ideas to try to mitigate the issues: - document the ABI (like we have in the ACPI spec) - use a specific prefix for all external calls (like _ for ACPI spec ones) - use a specific (different) prefix for all internal loaded calls (like [A-Z] for non-ACPI spec ones) Thoughts? > > This is a partially functional prototype. > > > > What works: > > loading _CST dynamically and reporting it to OSPM > > > > What doesn't: > > detecting host configuration and generating correct _CST package > > notifying guest about the change to trigger _CST re-evaluation > > disabling mwait/halt exists as appropriate > > > > Michael S. Tsirkin (6): > > acpi: aml: add aml_register() > > acpi: generalize aml_package / aml_varpackage > > acpi: aml_load/aml_unload > > acpi: export acpi_checksum > > acpi: init header without linking > > acpi: aml generation for _CST > > pc: HACK: acpi: tie in _CST object to Processor > > > > include/hw/acpi/acpi.h | 2 + > > include/hw/acpi/aml-build.h | 14 ++- > > include/hw/acpi/cst.h | 8 ++ > > include/hw/i386/pc.h | 5 ++ > > hw/acpi/aml-build.c | 81 ++++++++++++++--- > > hw/acpi/core.c | 2 +- > > hw/acpi/cpu.c | 5 ++ > > hw/acpi/cpu_hotplug.c | 11 +-- > > hw/acpi/cst.c | 173 ++++++++++++++++++++++++++++++++++++ > > hw/arm/virt-acpi-build.c | 2 +- > > hw/i386/acpi-build.c | 10 ++- > > hw/acpi/Makefile.objs | 2 +- > > 12 files changed, 290 insertions(+), 25 deletions(-) > > create mode 100644 include/hw/acpi/cst.h > > create mode 100644 hw/acpi/cst.c > >