[libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
Avi Kivity
avi at redhat.com
Sun Mar 25 15:45:27 UTC 2012
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
More information about the libvir-list
mailing list