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

[Avi Kivity <avi@redhat.com>]

On 03/25/2012 08:01 PM, Anthony Liguori wrote:
>> I don't think this came out of happiness, but despair.  Seriously,
>> keeping compatibility is one of the things we work hardest to achieve,
>> and we can't manage it for our command line?
>
>
> I hate to burst your bubble, but we struggle and rarely maintain the
> level of compatibility you're seeking to have.
>
> I agree with you that we need to do a better job maintaining
> compatibility which is why I'm trying to clearly separate the things
> that we will never break from the things that will change over time.
>
> -nodefconfig is a moving target.  If you want stability, don't use
> it.  If you just want to prevent the user's /etc/qemu stuff from being
> loaded, use -no-user-config.

Fine, but let's clearly document it as such.

Note just saying it doesn't load any configuration files isn't
sufficient.  We have to say that it kills Westmere and some of its
friends, but preserves others like qemu64.  Otherwise it's impossible to
use it except by trial and error.

>
>>>
>>> I'm not saying that backwards compat isn't important--it is.  But
>>> there are users who are happy to live on the bleeding edge.
>>
>> That's fine, but I don't see how -nodefconfig helps them.  All it does
>> is take away the building blocks (definitions) that they can use when
>> setting up their configuration.
>
> Yes, this is a feature.

I don't see how, but okay.

>
>>>> Suppose we define the southbridge via a configuration file.  Does that
>>>> mean we don't load it any more?
>>>
>>> Yes.  If I want the leanest and meanest version of QEMU that will
>>> start in the smallest number of milliseconds, then being able to tell
>>> QEMU not to load configuration files and create a very specific
>>> machine is a Good Thing.  Why exclude users from being able to do this?
>>
>> So is this the point?  Reducing startup time?
>
> Yes, that's one reason.  But maybe a user wants to have a whole
> different set of machine types and doesn't care to have the ones we
> provide.  Why prevent a user from doing this?

How are we preventing a user from doing it?  In what way is -nodefconfig
helping it?

> Maybe they have a management tool that attempts to totally hide QEMU
> from the end user and exposes a different set of machine types.  It's
> certainly more convenient for something like the Android emulator to
> only have to deal with QEMU knowing about the 4 types of machines that
> it specifically supports.

If it supports four types, it should always pass one of them to qemu. 
The only thing -nodefconfig adds is breakage when qemu moves something
that one of those four machines relies on to a config file.

-- 
error compiling committee.c: too many arguments to function