User talk:Xiawenc

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