4:13 p.m.
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/msg0...
http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg0...
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/msg0...
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(a)redhat.com
7:44 a.m.
New subject: [libvirt] [virt-devel] [RHEL6 PATCH] Correct cpuid flags and "model" fields, V2
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
5200
days inactive
5201
days old
1 comments
2 participants
participants (2)
-
Jiri Denemark -
john cooper