The section "Guest CPU models" should be updated, comments below:

Background: 
- http://wiki.qemu.org/Features/CPUModels has the QEMU roadmap for relevant features
- rawhide/F20 is currently shipping qemu-1.5.1
- F19 is currently shipping qemu-1.4.2
- F18 is currently shipping qemu-1.2.2
- Fedora ships qemu-kvm as /usr/bin/qemu-kvm not /usr/libexec/qemu-kvm


The first part of the section states CPU configurations are defined in XML files rather than hardcoded; per the roadmap, they are again hardcoded to allow compatibility code and more unified processor definitions. There's no indication of backwards compatibility from qemu, although virsh and friends may still accept .conf definitions and Know What To Do when talking to qemu. 

In F18 and F19, `qemu-kvm -cpu ?cpuid` and `qemu-kvm -cpu ?dump` do not function.

In F18, `qemu-kvm -cpu ?` gives a terse list of definitions.
in F19, `qemu-kvm -cpu ?` gives a more descriptive list, and also includes a comprehensive list of recognized CPU flags. This could possibly replace `?cpuid`



In both, `qemu-kvm -cpu <name>,enforce` functions as expected; this content is commented out.

Looking further into comparing guest CPU features, I find `virsh capabilities` will generate xml representing the host. It also appears to represent other architectures that the host could emulate - if the appropriate packages (ie qemu-arm ) are installed, and I correctly understand what they do.

There's also `virsh cpu-baseline` to generate a cpu definition that would allow migration between file-defined hosts, and `virsh cpu-compare` to compare a defined host with the local host. Both of these rely on [deprecated] xml .conf cpu definition files. I haven't been able to find a more elegant way to compare cpu configurations than scripting together the above virsh commands, presuming `virsh capabilities` works the way I suspect.

The qemu roadmap cites `-cpu best` as a way to get the best CPU definition when creating a guest - but it doesn't work here, and I'm not sure how it would make a determination if it did.

A lot of the information I've discovered deals directly with qemu, not libvirt. With qemu moving back to hard coded cpu definitions, I think it would be good to get some insight on if libvirt tools are affected and how they are handling the change. In general, I think it would be better to present libvirt commands rather than commands executing qemu directly.

I'm not submitting a patch for this one because I'm not sure where to go with it. It *seems* like libvirt should have a simple way to compare the capabilities of heterogeneous hosts and aid in creating the best definitions for guests.