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

[Gleb Natapov <gleb@redhat.com>]

On Sun, Mar 11, 2012 at 09:16:49AM -0500, Anthony Liguori wrote:
> >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).
CPU models should be usable even with -nodefconfig. CPU model is more
like device. By -cpu Nehalem I am saying I want Nehalem device in my
machine.

> 
> 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?
> 
I was always against libvirt configuring low level details of CPU. What
it should do IMO is to chose best CPU model for host cpu (one can argue
that fiddling with /proc/cpuinfo is not QEMU busyness).

> >>(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?
> 
If for a user to have stable guest environment we require libvirt use
then QEMU by itself is less usable. We do have machine types in QEMU to
expose stable machine to a guest. CPU models should be part of it.

--
			Gleb.