[libvirt] [RHEL6 PATCH] Correct cpuid flags and "model" fields, V2

[john cooper]

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.cooper at redhat.com