Resurrecting an old thread: I didn't see any clear conclusion in this thread (this is why I am resurrecting it), except that many were arguing that libvirt should simply copy and/or generate the CPU model definitions from Qemu. I really don't think it's reasonable to expect that.
On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote: > Hi, > > Recently I realized that all modern CPU models defined in > /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. > That's because we start qemu with -nodefconfig which results in qemu ignoring > that file with CPU model definitions. We have a very good reason for using > -nodefconfig because we need to control the ABI presented to a guest OS and we > don't want any configuration file that can contain lots of things including > device definitions to be read by qemu. However, we would really like the new > CPU models to be understood by qemu even if used through libvirt. What would > be the best way to solve this? > > I suspect this could have been already discussed in the past but obviously a > workable solution was either not found or just not implemented. So, our problem today is basically: A) libvirt uses -nodefconfig; B) -nodefconfig makes Qemu not load the config file containing the CPU model definitions; and C) libvirt expects the full CPU model list from Qemu to be available. Those three expectations can't be fulfilled at the same time. So, we have to break one of the expectations above. That means: - Breaking (A), that would mean libvirt wouldn't use -nodefconfig. I think -nodefconfig _has_ a point, even if it doesn't do much today, so I think we can drop this possibility. - Breaking (B), that means loading the CPU model definitions anyway when using -nodefconfig. I am inclined for this option: the list of CPU model defs are a list of CPU "templates", not actual virtual machine configuration. The fact that the CPU templates are stored in an external file instead of hardcoded inside the Qemu source code is just an implementation detail. A more detailed explanation is below. - Breaking (C), that means libvirt would simply not have the existing CPU model definitions available for its use. This is what happens today. The problem with this solution is: if we are spending lots of efforts defining properly all those CPU definition templates, we should allow the upper layers to reuse them, instead of forcing them to duplicate work and maintain their own copies and deal with exactly the same problems we had to deal inside Qemu. This is related to the argument that "CPU definitions are part of machine-types". Machine-types are a mechanism to allow new guest-visible features to be added to a virtual machine without waiting until libvirt can handle the details of that feature. You just choose a newer machine-type, and the new features are going to be enabled, even if libvirt doesn't know anything about it. When libvirt starts to model some details of some feature, we can let it probe for them, so it knows what's exactly being exposed to a guest. But while these details are not modelled by libvirt, the only way we can let the user enjoy new features as they are available is using machine-types. And to make this work, machine-types details can't be disabled using -nodefconfig. Complementing what Gleb said at that time: On Sun, Dec 18, 2011 at 11:58:16AM +0200, Gleb Natapov wrote: > > Ideally libvirt would just write out a config file with the CPU > > that was configured in libvirt and pass -readconfig > > /var/lib/libvirt/qemu/guestcpu.conf > > That way libvirt can configure CPU models without regard for > > what the particular QEMU version might have in its config. > > > And how libvirt would know that particular QEMU/kvm version can create > this CPU. Managing cpuid shouldn't be libvirt busyness. Even if managing CPUID bits is libvirt business on some specific cases, this is not true for _all_ CPU details. I don't think that the libvirt internal model of CPU features will be ever complete (and maybe it even shouldn't be). There will be always some feature that libvirt don't know anything about, and _that_ is what we have to model inside the Qemu CPU definitions and/or inside machine-type definitions--I don't think we even have a choice. We can make it easier to change and probe for the existing CPU definitions and features, in case libvirt wants to deal with some details, but we can't expect libvirt to be able to configure every single detail about the CPU. -- Eduardo
