User talk:Xiawenc

From QEMU
Revision as of 07:03, 18 January 2013 by Xiawenc (talk | contribs)

VM backup enhancement

Summary

This feature will enhance VM backup functionality, to make it possible taking internal/external snapshots lively, and make it works better with underlining components such as LVM.

Owner

  • Name: Wenchao Xia
  • Email: xiawenc@linux.vnet.ibm.com, xiaxia347os@163.com

Detailed Summary

Provide APIs that can do:

  • 1 block device live snapshot as internal/external/blank delta data, export sync API for all type.
  • 2 vmstate live save as internal/external data, export async API for external data, fix the size problem.
  • 3 combination(internal block snapshot + internal vmstate save, internal block snapshot + internal vmstate).

Roadmap

QEMU 1.4

  • Make CPU a subclass of DeviceState (included)
  • APIC-ID-related topology fixes (ehabkost) (RFC submitted)
  • Fixes for -cpu enforce flag
  • CPU feature words refactor

After QEMU 1.4

  • x86 CPU properties (Igor Mammedov)
    • Being redone to use static properties
  • machine-friendly error reporting of -cpu enforce/check
  • x86 CPU model subclasses
  • Allow changing of Hypervisor CPUIDs (Don Slutz)
  • Probing for CPU features supported by the host and can be enabled
  • Probing for the features that are actually enabled on each CPU model

Already done

  • Drop "-cpu ?dump" (Peter Maydell)
  • Move CPU models to C code (ehabkost)
  • Eliminate cpudef config section support (ehabkost)
  • "unduplicate feature names" series (ehabkost)
  • -cpu host use GET_SUPPORTED_CPUID (ehabkost)
  • add feature flag name list for CPUID 7

Current Issues and proposed changes

Allowing CPU models to be updated

We need a mechanism to allow the existing CPU models on Qemu to be updated, without making guest-visible changes for existing Virtual Machines, when migrating to a new version.

Examples

Examples where CPU model updates are necessary and have to be deployed to users:

  • The Nehalem CPU model currently has the wrong "level" value, making CPU topology information unavailable.
  • The CPUID PMU leaf was added on Qemu 1.1, but it is not supposed to be visible to guests running using -M pc-1.0
  • New features are implemented by KVM and we may want to add them to existing models (e.g. SandyBridge may need to have tsc-deadline added)

Requirements

  • A different CPU will be visible to the guest depending on the machine-type chosen.
    • That means that "-M pc-1.0 -cpu Nehalem" will be different from "-M pc-1.1 -cpu Nehalem"
    • Rationale:
      • The meaning of "-M pc-1.0 -cpu Nehalem" can't be changed or it will change existing guests
      • The meaning of "-M pc-1.1 -cpu Nehalem" needs to be different from the pc-1.0 one, otherwise we would be stuck with a broken "Nehalem" model forever

Current design proposal

  • CPU model definitions were moved to C code, so we can easily add compatibility code to them if necessary
  • CPUs are now DeviceState objects
  • CPU models will become separate classes, so per-CPU-model compatibility properties can be used on machine-type definitions


Probing of CPU model details

libvirt don't write CPU definitions from scratch, so it will reuse the CPU models from /usr/share. But it needs to probe for details of the CPU models.

Requirements

A detailed probing system, similar to "-cpu ?dump", but in a more extensible and machine-friendly format.

Current design proposal

  • -query-capabilities RFC series from Anthony
    • Message-Id: <1332169763-30665-9-git-send-email-aliguori@us.ibm.com>
  • To be defined: Command to list CPU models, and the features they include/exclude
  • To be defined: Command to list the resulting CPUID bits of CPU models
    • Do we need a version that works before the VM is created? Some bits depend on other Virtual Machine parameters (e.g. SMP configuration), so it won't list every single bit
    • Do we need a version that works after the VM is created, so it lists every single bit? (maybe just the "query-cpus" QMP command is already enough for that)
      • Probably the final solution will require libvirt to actually create a VM and run a "query-cpus" (or similar) command to get the resulting CPUID bits
  • To be defined: command to query which CPU flags are really available and can be enabled (based on host hardware + kernel + qemu capabilities)

-cpu host and feature probing

See http://article.gmane.org/gmane.comp.emulators.kvm.devel/90035

-cpu host vs -cpu best

Currently we have -cpu host, but the naming and semantics are unclear.

We have 3 possible modes of "try to get the best CPU model":

  1. all-you-can-enable: Enable every single bit that can be enabled, including the ones not present on the host but that can be emulated.
  2. match-host-CPU: Enable all bits that are present in the host CPU that can be enabled.
  3. best-predefined-model: Use the best CPU model available from the pre-defined CPU model list.

Proposal

  • -cpu host will be the "all-you-can-enable" mode, that will enable every bit from GET_SUPPORTED_CPUID on the VCPU
  • The best-predefined-model will be implemented using -cpu best.
  • We're not going to have a mode for match-host-CPU, probably