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

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.

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