Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Gleb Natapov]

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.

> (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.

> 
> (And I really hope that there's no plan to require all those low-level
> bits to appear as-is on the libvirt XML definitions. Because that would
> require users to read the Intel 64 and IA-32 Architectures Software
> Developer's Manual, or the AMD64 Architecture Programmer's Manual and
> BIOS and Kernel Developer's Guides, just to understand why something is
> not working on his Virtual Machine.)
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=689665
> 
> -- 
> Eduardo

--
                        Gleb.