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. 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. Thanks, -john http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg01110.html http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg00831.html john cooper wrote: > Addresses BZs: > > #618332 - CPUID_EXT_POPCNT enabled in qemu64 and qemu32 built-in models. > #613892 - [SR-IOV]VF device can not start on 32bit Windows2008 SP2 > > Summary: > > CPU feature flags for several processor definitions require correction > to accurately reflect the corresponding shipped silicon. In particular > overly conservative values for cpuid "model" fields cause disable of > MSI support in windows guests (BZ #613892). Also recent upstream changes > of qemu64's built-in definition enables POPCNT (for the benefit of TCG) > but risks kvm migration breakage (BZ #618332). The following patch > address these issues collectively. > > Changes relative to previous version: > > - drop of the "qemu32-rhel5" model as it appears to be unneeded. > > - rename of "qemu64-rhel?" to "cpu64-rhel?" as we're diverging from > upstream qemu64's definition but haven't migrated to kvm64 quite yet. > > - Correction of several fields for the (now) cpu64-rhel5 model. > > Further detail may be found in the associated mail thread common to > both BZ cases starting about here: > > > http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg00831.html > > Brew Build: > > https://brewweb.devel.redhat.com/taskinfo?taskID=2643552 > > Upstream status: > > BZ #618332 is a local, interim change and doesn't relate to upstream > concerns. Longer-term this qemu64 derived model would be displaced > by kvm64. The update of cpu definitions (BZ #613892) however needs > to be pushed upstream upon validation in rhel6. We're currently the > sole users of the new cpu models which fosters this inverted process. -- john.coo...@redhat.com -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
