Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
On 03/25/2012 10:18 AM, Avi Kivity wrote:
> On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>>
>>
>> -nodefconfig is going to eventually mean that -cpu westmere and -M
>> pc-1.1 will not work.
>>
>> This is where QEMU is going. There is no reason that a normal user
>> should ever use -nodefconfig.
>
> I don't think anyone or anything can use it, since it's meaning is not
> well defined. "not read any configuration files" where parts of qemu
> are continually moved out to configuration files means its a moving
> target.
I think you assume that all QEMU users care about forward and
backwards compatibility on the command line about all else.
That's really not true. The libvirt folks have stated repeatedly that
command line backwards compatibility is not critical to them. They
are happy to require that a new version of QEMU requires a new version
of libvirt.
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'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.
> 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?
I can't say I see the reason to invest so much effort in shaving a
millisecond or less from this, but if we did want to, the way would be
lazy loading of the configuration where items are parsed as they are
referenced.
--
error compiling committee.c: too many arguments to function