[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
- From: Eduardo Habkost <ehabkost redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: libvir-list redhat com, Jiri Denemark <jdenemar redhat com>, Avi Kivity <avi redhat com>, qemu-devel nongnu org
- Subject: Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
- Date: Mon, 26 Mar 2012 13:34:25 -0300
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- ARCH@.cfg',
> >> '@DATADIR@/system.cfg', '@DATADIR@/system- ARCH@.cfg']
> >>2) system- ARCH@.cfg will contain:
> >>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?
> 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- 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
> >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.
> We don't have a formal concept of -read-definition-config and
> 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
> >>>>>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
> >>>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
> 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
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".
[Date Prev][Date Next] [Thread Prev][Thread Next]