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

[Eduardo Habkost]

On Sun, Mar 25, 2012 at 01:11:04PM -0500, Anthony Liguori wrote:
> On 03/25/2012 10:40 AM, Avi Kivity wrote:
> >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?
> 
> Okay, we can just drop -no-user-config and then if a management tool
> wants to do the equivalent, they can do -nodefconfig + '-readconfig
> @DATADIR@/system- at ARCH@.cfg'.  I'm equally happy with that :-)

I actually prefer -no-user-config, because it gives Qemu freedom to add
more stuff to the outside if needed, but without requiring more
-readconfig options (or -read-something-else options, if we create them)
to be added in the future.

For example, if one day we move machine-types to external files, libvirt
wouldn't have to be changed to add Yet Another -readconfig argument to
make the machine-types available for use. If Qemu moves some device
implementation to external modules, they won't suddenly go away for
users of -no-user-config. The list of possible changes that would break
compatibility for -nodefconfig users but no -no-user-config users is
large.

[...]
> >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.

Well, you make the assumption that somebody will every want to use
-nodefconfig the way you want to define it. I don't think nobody will
ever use it if we defined it that way, but that's OK with me. I will
simply ignore the existence of -nodefconfig from now on.  :-)

[...]
> >>>"#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.

The distinction _is_ meaningful to libvirt, that's what started this
thread.

[...]
> >>>>>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).
> 
> 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).

And libvirt needs a way to keep module autoloading enabled while
disabling the loading of files from /etc.

> 
> You can imagine this being useful for something like Common Criteria certifications.

No problem, except that this is not the use-case libvirt has. If you
want -nodefconfig to mean that, that's OK. But we need an option to just
disable the loading of files from /etc, but keeping loading the "default
non-user-configurable modules that usually are available" (be it CPU
models, machine-types, external modules, whatever), and doesn't keep
changing meaning on every minor release.

[...]
> >>>-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?
> 
> It's obviously defined for a given release, just not defined long term.

Then it's not usable by libvirt.

[...]
> >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.

Then we need an option with the meaning that libvirt needs, and a
meaning that is stable across releases. If I understood this dicussion
correctly, that would be "-no-user-config".

-- 
Eduardo