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

[Avi Kivity <avi@redhat.com>]

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-@ARCH@.cfg',
>          '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
>
> 2) system-@ARCH@.cfg will contain:
>
> [system]
> readconfig=@DATADIR@/target-@ARCH@-cpus.cfg
> readconfig=@DATADIR@/target-@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