Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Daniel P. Berrange]

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