A question arose in today's kvm meeting concerning any impact to libvirt from this change. I've discussed it with Cole and it seems to be a non-issue. But just to err on the side of caution, here's a summary:
The current cpu model definition of "qemu64" upstream is problematic from kvm's perspective such that we need to modify it slightly (BZ justifications listed below). Doing so we've left the qemu64 definition as-is, but added "cpu64-rhel6" and "cpu64-rhel5" models which are now selected by default via "-M <machine>", for "RHEL 6.0.0 PC" and "RHEL 5.x.y PC" respectively.
I was following the whole thread and I would have stepped in in case libvirt was affected by the change. Still, thanks for keeping libvirt on your mind.
So the only issue would be libvirt invoking qemu with neither a "-cpu" nor "-M" argument (which defaults to qemu64) or explicitly requesting "-cpu qemu64".
From my discussion with Cole it appears the use cases where this may happen fall outside of routine/expected usage and would need to be explicitly requested by the user. However I wanted to call this out here in the event we're overlooking something.
Yeah, libvirt basically never runs qemu without -M option and the only way to get -cpu qemu64 is to explicitly ask for it in guest XML. There is a scenario when libvirt creates -cpu option for qemu even though no cpu requirements were specified in guest XML but it only happens for 32b guests on 64b hosts and qemu32 CPU model is used in that case, which should be OK since the problem is only about qemu64. And IIUC we don't want users to be able to specify the new cpu64-rhel[56] models directly in guest XML so there's nothing to be done on libvirt side. Jirka