qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH hack dontapply v2 0/7] Dynamic _CST generation


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH hack dontapply v2 0/7] Dynamic _CST generation
Date: Wed, 25 Jul 2018 14:32:11 +0200

On Tue, 10 Jul 2018 03:01:30 +0300
"Michael S. Tsirkin" <address@hidden> 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?

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

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]