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

>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?