Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
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