On Mon, Jun 08, 2015 at 10:18:35PM +0200, Jiri Denemark wrote: > On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote: > ... > > libvirt can solve this problem partially by making sure every feature in a > > CPU > > model is explicitly configured, instead of (incorrectly) expecting that a > > named > > CPU model will never change in QEMU. But this doesn't solve the problem > > completely, because it is still possible that new features unknown to > > libvirt > > get enabled in the default CPU model in future machine-types (that's very > > likely to happen when we introduce new KVM features, for example). > > > > So, to make sure no new feature will be ever enabled without the knowledge > > of > > libvirt, add a "-cpu custom" mode, where no CPU model data is loaded at all, > > and everything needs to be configured explicitly using CPU properties. That > > means no CPU features will ever change depending on machine-type or > > accelerator > > capabilities when using "-cpu custom". > > > > * * * > > > > I know that this is basically the opposite of what we were aiming at in the > > last few month^Wyears, where we were struggling to implement probing > > interfaces > > to expose machine-type-dependent data for libvirt. But, at least the fact > > that > > we could implement the new approach using a 9-line patch means we were still > > going in the right direction. :) > > > > To help libvirt in the transition, a x86-cpu-model-dump script is provided, > > that will generate a config file that can be loaded using -readconfig, > > based on > > the -cpu and -machine options provided in the command-line. > > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU > configuration data to libvirt, but now I think it actually makes sense. > We already have a partial copy of CPU model definitions in libvirt > anyway, but as QEMU changes some CPU models in some machine types (and > libvirt does not do that) we have no real control over the guest CPU > configuration. While what we really want is full control to enforce > stable guest ABI.
I meanwhile, always wanted the full CPU config data in libvirt, so that we could ensure libvirt was able to use the exact same CPU model setup on other hypervisors too - eg Xen, VMWare let us specify the CPUID masks so we could re-use the libvirt data there. > I will summarize my ideas on how libvirt should be using -cpu custom and > send them to libvirt-list soon. These patches are x86 obviously - is there anything we need to worry about for non-x86 architectures I wonder ? IIRC, all the non-x86 archs have traditionally only needed CPU model names and don't really have the same level of per-flag CPUID mask configurability that x86 has. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|