On 03/11/2012 07:41 AM, Gleb Natapov wrote:
On Sat, Mar 10, 2012 at 12:58:43PM -0300, Eduardo Habkost wrote:
On Sat, Mar 10, 2012 at 12:42:46PM +0000, Daniel P. Berrange wrote:
I could have sworn we had this discussion a year ago or so, and had decided
that the default CPU models would be in something like /usr/share/qemu/cpu-x86_64.conf
and loaded regardless of the -nodefconfig setting. /etc/qemu/target-x86_64.conf
would be solely for end user configuration changes, not for QEMU builtin
defaults.
But looking at the code in QEMU, it doesn't seem we ever implemented this ?
Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but,
contrary to our normal RHEL development practice, it was not based on
a cherry-pick of an upstream patch :-(
For sake of reference, I'm attaching the two patches from the RHEL6 source
RPM that do what I'm describing
NB, I'm not neccessarily advocating these patches for upstream. I still
maintain that libvirt should write out a config file containing the
exact CPU model description it desires and specify that with -readconfig.
The end result would be identical from QEMU's POV and it would avoid
playing games with QEMU's config loading code.
I agree that libvirt should just write the config somewhere. The problem
here is to define: 1) what information should be mandatory on that
config data; 2) who should be responsible to test and maintain sane
defaults (and where should they be maintained).
The current cpudef definitions are simply too low-level to require it to
be written from scratch. Lots of testing have to be done to make sure we
have working combinations of CPUID bits defined, so they can be used as
defaults or templates. Not facilitating reuse of those tested
defauls/templates by libvirt is duplication of efforts.
Really, if we expect libvirt to define all the CPU bits from scratch on
a config file, we could as well just expect libvirt to open /dev/kvm
itself and call the all CPUID setup ioctl()s itself. That's how
low-level some of the cpudef bits are.
s/some/all
If libvirt assumes anything about what kvm actually supports it is
working only by sheer luck.
Well the simple answer for libvirt is don't use -nodefconfig and then it can
reuse the CPU definitions (including any that the user adds).
Really, what's the point of having a layer of management if we're saying that
doing policy management is too complicated for that layer? What does that layer
exist to provide then?
(Also, there are additional low-level bits that really have to be
maintained somewhere, just to have sane defaults. Currently many CPUID
leafs are exposed to the guest without letting the user control them,
and worse: without keeping stability of guest-visible bits when
upgrading Qemu or the host kernel. And that's what machine-types are
for: to have sane defaults to be used as base.)
Let me give you a practical example: I had a bug report about improper
CPU topology information[1]. After investigating it, I have found out
that the "level" cpudef field is too low; CPU core topology information
is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu
have level=2 today (I don't know why). So, Qemu is responsible for
exposing CPU topology information set using '-smp' to the guest OS, but
libvirt would have to be responsible for choosing a proper "level" value
that makes that information visible to the guest. We can _allow_ libvirt
to fiddle with these low-level bits, of course, but requiring every
management layer to build this low-level information from scratch is
just a recipe to waste developer time.
And QEMU become even less usable from a command line. One more point to
kvm-tool I guess.
I'm not sure what your point is. We're talking about an option that humans
don't use. How is this a discussion about QEMU usability?
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list