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

[Avi Kivity <avi@redhat.com>]

On 03/25/2012 08:11 PM, Anthony Liguori wrote:
>
>> 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.
>
> *if the user doesn't know specifics about this QEMU version.
>
> You make the assumption that all users are going to throw arbitrary
> options at arbitrary QEMU versions.  That's certainly an important
> use-case but it's not the only one.

If a Fedora user is using qemu, then their qemu version will change
every six months.  Their options are to update their scripts/management
tool in step, or not have their management tool use -nodefconfig.

The same holds for anyone using qemu from upstream, since that's
approximately the qemu release cycle.

>
>> -no-user-config is usable, I think it needs also to mean that qemu
>> without -M/-cpu/-m options will error out?
>
> You're confusing -nodefaults (or something stronger than -nodefaults)
> with -no-user-config.
>

Right.

> Yes, the distinctions are confusing.  It's not all fixable tomorrow. 
> If we take my config refactoring series, we can get 90% of the way
> there soon but Paolo has a more thorough refactoring..
>
>>>> "#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.
>
> We don't have a formal concept of -read-definition-config and
> -read-configuration-config
>
> There's no easy or obvious way to create such a concept either nor do
> I think the distinction is meaningful to users.

Definition files should be invisible to users.  They're part of the
implementation.  If we have a file that says

  pc-1.1 = piix + cirrus + memory(128) + ...

then it's nobody's business if it's in a text file or a .c file.

Of course it's  nice to allow users to load their own definition files,
but that's strictly a convenience.

>> 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).
>
>
> At some point, I'd like to have type modules that are shared objects. 
> I'd like QEMU to start with almost no builtin types and allow the user
> to configure which modules get loaded.
>
> In the long term, I'd like QEMU to be a small, robust core with the
> vast majority of code relegated to modules with the user ultimately in
> control of module loading.
>
> Yes, I'd want some module autoloading system but there should always
> be a way to launch QEMU without loading any modules and then load a
> very specific set of modules (as defined by the user).
>
> You can imagine this being useful for something like Common Criteria
> certifications.

Okay.

> It's obviously defined for a given release, just not defined long term.
>
>> 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.
>
> That's not even close to what -nodefconfig is.  That's pretty much
> what -nodefaults is but -nodefaults has also had a fluid definition
> historically.

Okay.  Let's just make sure to document -nodefconfig as version specific
and -nodefaults as the stable way to create a bare bones guest (and
define exactly what that means).

-- 
error compiling committee.c: too many arguments to function