[libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
Avi Kivity
avi at redhat.com
Sun Mar 25 15:40:13 UTC 2012
On 03/25/2012 05:26 PM, Anthony Liguori wrote:
>> Put the emphasis around *configuration*.
>
>
> So how about:
>
> 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
> '@SYSCONFDIR@/qemu/target- at ARCH@.cfg',
> '@DATADIR@/system.cfg', '@DATADIR@/system- at ARCH@.cfg']
>
> 2) system- at ARCH@.cfg will contain:
>
> [system]
> readconfig=@DATADIR@/target- at ARCH@-cpus.cfg
> readconfig=@DATADIR@/target- at ARCH@-machine.cfg
>
> 3) -nodefconfig will not load any configuration files from DATADIR or
> SYSCONFDIR. -no-user-config will not load any configuration files
> from SYSCONFDIR.
What, more options?
I don't think -nodefconfig (as defined) is usable, since there is no way
for the user to tell what it means short of reading those files.
-no-user-config is usable, I think it needs also to mean that qemu
without -M/-cpu/-m options will error out? since the default machine/cpu
types are default configuration.
>
>> "#define westmere blah" is not configuration, otherwise the meaning of
>> configuration will drift over time.
>>
>> -cpu blah is, of course.
>
> It's the same mechanism, but the above would create two classes of
> default configuration files and then it becomes a question of how
> they're used.
Confused.
>
>>>> The file defines westmere as an alias for a grab bag of options.
>>>> Whether it's loaded or not is immaterial, unless someone uses one
>>>> of the
>>>> names within.
>>>
>>> But you would agree, a management tool should be able to control
>>> whether class factories get loaded, right?
>>
>> No, why? But perhaps I don't entirely get what you mean by "class
>> factories".
>>
>> Aren't they just implementations of
>>
>> virtual Device *new_instance(...) = 0?
>>
>> if so, why not load them?
>
> No, a class factory creates a new type of class. -cpudef will
> ultimately call type_register() to create a new QOM visible type.
> From a management tools perspective, the type is no different than a
> built-in type.
Exactly. The types are no different, so there's no reason to
discriminate against types that happen to live in qemu-provided data
files vs. qemu code. They aren't instantiated, so we lose nothing by
creating the factories (just so long as the factories aren't
mass-producing objects).
>
>>>> Otherwise, the meaning of -nodefconfig changes as more stuff is moved
>>>> out of .c and into .cfg.
>>>
>>> What's the problem with this?
>>
>> The command line becomes unstable if you use -nodefconfig.
>
> -no-user-config solves this but I fully expect libvirt would continue
> to use -nodefconfig.
I don't see how libvirt can use -nodefconfig with the fluid meaning you
attach to it, or what it gains from it.
>>
>> -nodefconfig = create an empty machine, don't assume anything (=don't
>> read qemu.cfg) let me build it out of all those lego bricks. Those can
>> be defined in code or in definition files in /usr/share, I don't care.
>>
>> Maybe that's -nodevices -vga none. But in this case I don't see the
>> point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the
>> user anything, since it wouldn't affect the guest in any way.
>
>
> -nodefconfig doesn't mean what you think it means. -nodefconfig
> doesn't say anything about the user visible machine.
>
> -nodefconfig tells QEMU not to read any configuration files at start
> up. This has an undefined affect on the user visible machine that
> depends on the specific version of QEMU.
Then it's broken. How can anyone use something that has an undefined
effect?
If I see something like -nodefconfig, I assume it will create a bare
bones guest that will not depend on any qemu defaults and will be stable
across releases. I don't think anyone will understand -nodefconfig to
be something version dependent without reading the qemu management tool
author's guide.
--
error compiling committee.c: too many arguments to function
More information about the libvir-list
mailing list